From: zimoun <zimon.toutoune@gmail.com>
To: Christopher Baines <mail@cbaines.net>, guix-devel@gnu.org
Subject: Re: Proposed change for the disruptive changes process (staging/core-updates)
Date: Fri, 11 Dec 2020 15:30:06 +0100 [thread overview]
Message-ID: <868sa4h0up.fsf@gmail.com> (raw)
In-Reply-To: <877drg3lmi.fsf@cbaines.net>
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
prev parent reply other threads:[~2020-12-11 14:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 17:20 Proposed change for the disruptive changes process (staging/core-updates) Christopher Baines
2020-12-11 14:30 ` zimoun [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=868sa4h0up.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=guix-devel@gnu.org \
--cc=mail@cbaines.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).