Re: gnu: inetutils: Update to 2.4.

[Andreas Enge]

Am Tue, Mar 14, 2023 at 09:10:33PM -0400 schrieb Maxim Cournoyer:
> Could you share the reference of that?  I'm not against it, but our
> currently documented process still mention the good old staging and
> core-updates branches.

It has not been documented yet, we should do it.
Here is the relevant excerpt from my notes, sent to guix-devel on
February 9 under the title "Discussion notes on releases and branches":
- Create branches with a few patches or patchsets; in any case with
  a "semantic" description of the changes. The branches could be
  shortlived. Feature branches are one incarnation of the concept.
- The numerical criteria for staging and core-updates is outdated:
  Even non-core packages may create an enormous number of rebuilds.
- Negative point: There is a risk of churn, by not regrouping world-
  rebuilding changes - but two non related world rebuilding changes
  might be difficult to review.
...
- There is discussion whether we need a core-updates branch.
  Core updates concern the toolchain, build phase changes, everything
  that has big ramifications all over the system. It would be important
  to not have several "parallel" branches with related (for instance,
  but not exclusively, core-update) changes, which in fact should come
  one after the other. Either they could be collected in one branch,
  or would require coordination of branch creation (inside a team, say).
- "Merge trains" of gitlab are mentioned, as a way of merging several
  branches at the same time.

There was a consensus on advancing in this direction, but details need to
be fleshed out.

The core argument I see against core-updates (and staging) is that they
regroup a mixed bag of unrelated changes, that noone is able to audit
after a while. By matching a focused set of changes with a dedicated team
of people competent in the area, we hope to advance faster and in a more
concentrated fashion. This comes in a context where our compile power in
the berlin build farm is much larger than in the past, and where on the
other hand a growing number of packages lead to non-core packages causing
a number of rebuilds that used to go to core-updates (like we just see
with inetutils).

> Until everybody has a good grasp of the new process, I think sticking to
> the documented one may be best for now, as it makes it clear that this
> cause a mass rebuild and shouldn't land to master.

Definitely in all procedures, old or new, mass rebuilds should not be done
in master!

Andreas