On 2025-11-14, Maxim Cournoyer wrote: > Noé Lopez <noe@noé.eu> writes: >> Maxim Cournoyer <[email protected]> writes: >>> Andreas Enge <[email protected]> writes: >>>> the current policy is to not merge to master, but to only push on top. >>>> This is not consistent with your proposal, Maxim. It is not set in >>>> stone, but we should also not change the policy without thorough >>>> discussion (and maybe a GCD). My suggestion would be to follow the >>>> agreed-upon release process for now, and then in the subsequent >>>> discussion period bring up problems (your concern may or may not turn >>>> out to be a big blocker) and modify the release process accordingly. >>>> But let us not change the process in the middle of our first release >>>> since years ago. >>> >>> We're only discussing changing a detail that would likely make it easier >>> for everyone. My fear here is that branches being worked on such as the >>> Python branches, Qt, etc. are held back for a couple weeks (if >>> everything goes as plan) "just because". Working on a release branch >>> and not blocking built branches merges to master while doing so appears >>> win-win to me. It's also simpler to manage from a CI/QA point of view. >>> >> >> They are not held back, they are just merged to a different branch. > > Good point, I had overlooked that. Still, it assumes every of the 47 > current Guix committers will have read this and not make any mistake and > push their large branch to master after it's been built by CI and QA. > > Having a distinct release branch would avoid the extra communication > needed here and prevent the unavoidable mistakes.
This seems to be the most compelling point ... I could easily see folks even accidentally pushing something inappropriate to master, even if they know that master was in the release preparation phase, as that is the usual workflow and there is nothing (to my knowledge) technically to prevent it from happening... I do not have a specific count, but I feel like there were a handful of massive rebuilds accidentally pushed to master a few times over the last year (some reverted, some not?), as a similar example where the policy does not stop people from these sorts of (hopefully innocent) mistakes. Seems like it could be the same for pushing to master during a release freeze of any form. So, while I very much welcomed the idea that the master branch would maybe occasionally slow down a bit during release preparation (which feels fine and cozy to me, coming from Debian)... the practicality of actually "enforcing" it may be more difficult than initially realized. At the danger of slipping towards off-topic, it really makes me wish guix had "guix pull" default to some branch other than master, so that master could just get all the latest changes, but only gets manually fast-forward merged into whatever branch "guix pull" pulls by default after some checks have passed, packages built, etc. ... live well, vagrant
signature.asc
Description: PGP signature
