unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Christopher Baines <mail@cbaines.net>
Cc: guix-devel@gnu.org
Subject: Re: Cleaning up branches on savannah
Date: Tue, 11 Jun 2024 11:16:59 -0400	[thread overview]
Message-ID: <87cyon8q61.fsf@netris.org> (raw)
In-Reply-To: <87sexo26pz.fsf@cbaines.net>

Hi Christopher,

Christopher Baines <mail@cbaines.net> writes:

> I think the easy process change is to delete the gnuzilla-updates branch
> once you've pushed the chagnes to master. That should make it clearer
> that there's effectively nothing on that branch.

Okay, I'll do that from now on.

> This shouldn't cause any problems for ci.guix.gnu.org (it hasn't when
> this has been tested in the past).

This was my main worry about deleting the branch, but based on what you
wrote above, I'll assume for now that it will not cause problems for
ci.guix.gnu.org.

> More generally, I think this is the kind of change that hopefully could
> be tested through QA. That would mean sending a patch series to
> guix-patches and then checking qa.guix.gnu.org for the results. Whether
> this would take more time or more work is another question though as QA
> has not been keeping up lately.

For IceCat updates, which almost always include security fixes, it is
important to have very fast turnaround time on the test results.
ci.guix.gnu.org normally starts building the new IceCat within an hour
or so of the update being pushed to 'gnuzilla-updates', and usually
finishes the build within 4-5 hours.  If, as you say, QA has not been
keeping up lately, then I'm not sure it will be fast enough for this use
case.

Also, I'd like to maximize the likelihood that substitutes for IceCat
updates will be available *immediately* upon pushing them to 'master'.
That's another motivation for pushing them to a temporary branch that
ci.guix.gnu.org has been configured to build.

Does that make sense?  I admit that I haven't been following the
evolution of Guix development processes much in recent years, nor do I
know much about the new QA system.  Please let me know if I have
misunderstood anything.

     Best regards,
         Mark


  reply	other threads:[~2024-06-11 15:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07  9:36 Cleaning up branches on savannah Christopher Baines
2024-06-07 12:46 ` Lars-Dominik Braun
2024-06-07 13:43 ` Mark H Weaver
2024-06-07 14:00   ` Christopher Baines
2024-06-11 15:16     ` Mark H Weaver [this message]
2024-06-12  9:11       ` Andreas Enge
2024-06-19 14:00       ` Christopher Baines
2024-06-19 14:03 ` Christopher Baines

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=87cyon8q61.fsf@netris.org \
    --to=mhw@netris.org \
    --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).