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.
