Maxim Cournoyer <[email protected]> writes: > Hi Noé, > > Noé Lopez via "Development of GNU Guix and the GNU System distribution." > <[email protected]> writes: > > [...] > >> We’re trying to follow the process suggested in GCD 005 as close as >> possible. As far as I understand, many choices have been made in it to >> prioritize having the releases done before anything else, so it was >> probably a conscious choice to make it easier for the release team. I am >> not the author though so I might be wrong. >> >> The GCD explains this rationale: >> >>>If there are major breaking changes that must be moved from a team >>>branch an integration branch will be created. For example next-master, >>>this will be short-lived, existing only until after the release. >>> >>>The master branch slows down from this week until the release. >>> >>>This concept comes from the Nix project where they flow big changes >>>into a staging branch while they do release stabilisation to prevent >>>big flows of breaking changes into master which broke one of their >>>releases ^6. >> >> The master branch will keep receiving any commit that is not a major >> change. Package additions, updates and fixes can still go there if they >> are “safe” enough. It does not become exclusive to the release team. >> >> Does that make sense? I’m sorry if it was not clear in my previous >> messages. > > It makes some sense, but it means every large branch (core packages, > python, mesa, etc.) will potentially be blocked while awaiting for > release, which seems like putting needless pressure on the release team > and introducing inefficiencies for rest of the project. > > I found what I had written back when the GCD 005 was proposed, in > <https://issues.guix.gnu.org/78332#87>: > >> I think the process should only impact the operations of the release >> team: that means not forcing everyone on a freeze, or a different >> branch, etc. The release team can simply branch from master to a >> release branch and refine it there. When it's done and released, it can >> be merged back into master. While trying to have teams synchronized for >> a release sounds good, I think in practice this will cause problems. So >> releasing should be orthogonal to the status/milestones of teams, in my >> opinion. Releasing often will make that less of a problem anyway. > > To which Steve (CC'd) had replied in <https://issues.guix.gnu.org/78332#89>: > >> At a practical level, in my experience the main reason why a >> distribution fails to hit it's release date is that another >> developer/team breaks the release by integrating some massive change >> that then invalidates all the QA. For a rolling release this >> specifically means making sure that the output of the initial install >> and then first user-experience of 'guix pull' works. > > If the release team was working on its own branch, there would be no way > someone pushing to master could break it; since it'd be distinct. Fixes > made for the test suites for example that would benefit master could be > cherry picked there, or the other way around, but the branch would > otherwise be isolated. >
Hi Maxim, That makes sense, and I think I agree to some extent. Let’s discuss it tonight with everyone at the release team meeting. Please feel free to come by. Otherwise I’ll send the meeting notes. Good day, Noé
signature.asc
Description: PGP signature
