Re: ‘core-updates’ is gone; long live ‘core-packages-team’!

["Ludovic Courtès" <ludo@gnu.org>]

Hey Steve,

Steve George <steve@futurile.net> skribis:

>> To reduce world rebuilds, perhaps we’ll sometimes create “merge trains”,
>> whereby we’ll merge, say, the branch upgrading CMake and that ungrafting
>> ibus on top of ‘core-packages-team’, and then merge this combination in
>> ‘master’.  The key being: these branches will have been developed and
>> tested independently of one another by dedicated teams, and the merge
>> train will be a mere formality.
>
> Under the 'patches and branches' workflow, what should happen to packages that are *not* part of any team, but do cause a rebuild of more than 300 dependent packages?
>
> Andy Tai gave an example of ffmpeg [0]. There aren't enough contributors or committers for every package to be covered by a team, so this seems like a permanent constraint even if more teams do grow over time.

As Chris noted, there’s no requirement for a branch to be associated
with a team; we won’t have teams for every possible package or package
set.

In the case of ffmpeg, I would suggest creating a “feature branch”
changing ffmpeg and only that (or possibly packages directly related to
ffmpeg).  We’d get that branch built so those working on it and ensure
it does not lead to any regression.

Once it’s “known good”, I see two possibilities:

  • Merge into ‘master’, especially if it turns out that binaries are
    already available on the build farms.

  • Attach to a “merge train”.  For instance, assume there’s a branch
    changing ‘gsl’: this is totally unrelated to ‘ffmpeg’ but it also
    triggers a lot of rebuilds.  We could tack that second branch on top
    of the known-good ‘ffmpeg’ branch, and, once it’s all good, merge
    that “train” into ‘master’.

(To be clear, the term “merge train” originates from GitLab-CI and
similar CI tool, which use it as a merge scheduling strategy:
<https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html>.  GitLab-CI
can create merge trains automatically I believe, but in our case we’d do
that manually, at least for now.)

> Long-lived branches and ones that don't cleanly apply onto master cause lots of difficulties from what I've seen. Perhaps a lesson is that branches should both be stateless *and* should not exist for more than 3 months. We already have a rule that encourages atomic changes within any patch in order to make things faster/easier to review. By extension, lets do the same with branches - merge them more often.

Agreed.  And I agree with what Chris wrote: the current wording (create
request to merge when the branch is created) should help reduce the risk
of having long-lived branches.

> I would propose a patch to the managing patches/branches sections of the manual depending on what the consensus is here.

I think this is a work-in-progress, so any improvement here is welcome
IMO.

Thanks,
Ludo’.