Re: [ITA] llvm

On 01/06/2025 22:56, Brian Inglis via Cygwin-apps wrote:
> On 2025-06-01 14:23, Jon Turney via Cygwin-apps wrote:
>> On 04/05/2025 07:59, ASSI via Cygwin-apps wrote:
>>> Takashi Yano via Cygwin-apps writes:
>>>> I pushed current working files in the packages
>>>> llvm
>>>
>>> Thereby obliterating all the work I'd done two years ago in getting the
>>> packaging halfway up to speed and making it a mess again.  Not
>>> impressed… :-(
>> Hmm... maybe this could be arranged better.
>>
>> The idea of playground branches was all a bit ad-hoc after I initially 
>> had things configured to only allow pushes to master (or main, I 
>> guess, now).
>>
>> Perhaps it's possible to give every maintainer a branch only they can 
>> create, push, force-push, rewind and delete?
>>
>> Or maybe I just need to allow branches named 'topic/*' which is the 
>> convention used elsewhere on sourceware for volatile, personal branches?
> 
> If it is in a repo, it can be rewound and replayed, or merged 
> differently, so nothing has been *obliterated*, although rework may be 
> required to tidy it up!

Not sure what you mean here.

The current configuration allows "non-fastforward" pushes to the 
playground branch (only).

By definition, these can erase history, since the reference now points 
to something which does not contain all of the previous commits.

> Allowing any maintainer to use playground branches or the playground 
> repo provides enough flexibility for our purposes.
> 
> Reading thru the Sourceware security policy requirements, all 
> maintainers, including those not yet using cygport, like g-b-s or their 
> personal hacks, should check in *ALL* build scripts required and include 
> them in their source packages, to provide an externally reproducible 
> source of packages.

I'm generally in agreement with you on this.

However, I believe that the correct approach to this problem is to 
improve our automated processes to ensure these things happen.

(Since I have neither the time, nor the inclination, to manually 
scrutinize every upload to ensure everything is done the way I'd 
personally like it, and hassling people about things like that seems 
like a good way to turn maintainers into ex-maintainers...)

I would very much like to turn off direct package uploads, so the only 
way to deploy packages is to have scallywag build them for you, which 
would solve this and several other problems.

Unfortunately, it was necessary to build the system first, before we can 
use it. (and it still needs several improvements...)

I guess I should start a thread to discuss that change...

> I have been uncomfortable for a long time with packages which can be 
> rebuilt or updated only by their maintainers, who rarely seem to monitor 
> the mailing lists.
> 
> If anything ever happens to their systems, they may be unable to rebuild 
> or update their packages, and there will be no possible alternatives, 
> other than starting from scratch.
I agree, but it's not quite that catastrophically bad: We have the 
source packages, which should contain the build scripts.

If you are aware of packages where that's not the case, please bring 
that up separately.