Feature branches (was: 04/09: gnu: mesa: Update to 23.0.3)

[Andreas Enge <andreas@enge.fr>]

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