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

[Ludovic Courtès]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> In this picture of “merge train”, the CI workload and world rebuilds
> will increase, no?
>
> Consider the two teams: science and this new core-packages.  Then
> science takes care of openblas (6000+ dependent packages) and
> core-packages of grep (6000+ dependent packages).
>
> When science team wants to merge to master, they ask for a rebuild.
>
> When core-packages team wants to merge to master, they ask for a
> rebuild.
>
> Therefore, we have two world rebuilds.  Or the both teams need to
> synchronize and thus the branches are indeed developed independently but
> not tested independently.  Are they?

I don’t have a clear answer to that.

The way I see it, one of the branches would be tested independently.
The second one would also be tested independently, but on a limited
scope—e.g., x86_64-only, because (1) we usually have more build power
for that architecture, and (2) perhaps we know the problems with those
branches are unlikely to be architecture-specific.

Then we’d rebase that second branch on top of the first one, and build
the combination for all architectures.

In the end, we do end up testing the combination of branches, but it’s
more structured than ‘core-updates’: each team has tested its own thing
and we got a better understanding of the impact of each change
independently.


I also think we shouldn’t be afraid of triggering rebuilds more
frequently than now, as long as build farms can keep up.  So there are
some changes that we’d previously lump together in ‘core-updates’ that I
would nowadays suggest having in a dedicated branch, merged
independently.

In the end, perhaps we’ll have to negotiate on a case-by-case basis.
The important thing to me is: independent testing as much as possible,
and well-defined responsibilities and scope for the people/teams
engaging in such changes.

Ludo’.