Re: Proposed change for the disruptive changes process (staging/core-updates)

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Fri, 23 Oct 2020 at 18:20, Christopher Baines <mail@cbaines.net> wrote:

> A simple process change that I think would help to address this is as
> follows (I'll use core-updates as the example, but this applies for
> staging as well):
>
>  - core-updates is effectively renamed to core-updates-next
>
>  - When you want to merge core-updates-next in to master, you create
>    core-updates pointing at the same commit as core-updates-next. This
>    begins the freeze.
>
>  - Once a sufficient amount of time has past for the things on
>    core-updates to have been built, you merge in to master
>
>  - Shortly after the merge to master, you then delete the core-updates
>    branch
>
> This would mean that a build server can track core-updates, and it'll
> only build things when they're relevant for substitutes. For
> ci.guix.gnu.org, maybe it could build both branches initially, to
> replicate the current setup, but I think in the long run, it would be
> helpful to separate out the behaviour so that ci.guix.gnu.org
> concentrates on builds for substitutes, and there's another thing for
> actually testing out potential core-updates changes.

Based on the current CI issues, and orthogonal with the Chris’s and
Mathieu’s effort (Build Coordinator and Cuirass)––thanks a lot for all
the tough work––I agree with this proposal.

And it would help to reduce the load on Berlin and so increase the
throughput of substitutes.

BTW, I agree that it seems better to separate what is “test” and what is
“production”, i.e., build on separate machines.  All the wip-* branches
could be built on Bayfront.  This implies a rebuild once merged but
somehow this rebuild already happens more than often.

All the best,
simon