Re: Feature branches

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> 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.

I like your above ideas; I'd like to add:

- I'd make the team branches permanent; e.g. the 'gnome-team' branch
  would always exist, and get synced periodically to master (when enough
  built/deemed stable).  This should reduce the overhead of constantly
  having to adjust the Cuirass specification jobs and serve as an
  integration point for the team (the Cuirass job specs would be defined
  declaratively in the guix-maintenance repository).

- branches judged too experimental to be merged into their team branch
  could be branched from it, with a name such as 'gnome-team/feature-x'
  to make it obvious where it should be merged when deemed ready.
  Cuirass job specifications for such short lived branches would be
  created manually using the Cuirass web interface (users need to be
  authorized as can be done following
  https://issues.guix.gnu.org/63375).

I don't think team branches should be merged together at any point,
ideally, to avoid loosing the benefits of feature branches (limited
scope).

-- 
Thanks,
Maxim