Hello, indeed someone™ should update the documentation to describe the new process. Probably we should agree on one before doing that as well... In principle all big updates should go through a feature branch now.
However, this does not solve the problem of limited build power in our two build farms. Having feature branches that regroup several related changes should help in not rebuilding too often. In principle it could also be okay to regroup unrelated changes (mesa and gcc, for instance), as long as responsibilities are clear. It should be known who is going to act on what when breakages occur in the branch. And I think there should be some kind of "branch manager" and a time frame for the merge so that the branches are short lived. The goal is to avoid the core-updates experience of random commits being dropped in the same place, while hoping that someone at some later point will sort it all out. So how about this suggestion: A feature branch is created upon request by a team, with a branch manager designated by the team. It is accompanied by a short description of what the branch is supposed to achieve, and in which timeframe. The branch manager has the responsibility to communicate regularly with guix-devel on the state of the branch and on what remains to be done, and requests to merge the branch to master once it is ready, and to subsequently delete the branch. This does not yet explain how the branches interact with continuous integration. The branch manager may or may not have commit rights and may or may not be able to create specifications for cuirass, so the full process should take this into account. As written in a different thread, right now I would also suggest to first build the branch only on x86 and powerpc to not overload our few arm machines, but this is a technical detail. Andreas
