Hi, On Fri, 23 Oct 2020 at 18:20, Christopher Baines <m...@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
