Hi, Noé Lopez <noe@noé.eu> writes:
> Maxim Cournoyer <[email protected]> writes: > >> Hi, >> >> Andreas Enge <[email protected]> writes: >> >>> Hello all, >>> >>> 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. -- Thanks, Maxim
