[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes to the branching workflow

From: Christopher Lemmer Webber
Subject: Re: Changes to the branching workflow
Date: Fri, 05 Mar 2021 10:34:21 -0500
User-agent: mu4e 1.4.15; emacs 27.1

zimoun writes:

> Hi, Chris,
> On Thu, 04 Mar 2021 at 16:05, Christopher Lemmer Webber 
> <> wrote:
>> I wonder if we should formalize it.  What about adding a section to the 
>> "Contributing" section of the manual explaining what the different
>> branches are, and when you have a patch that's been approved, when to
>> push it to which branch?
> Do you mean something like #8 in [1] and then [2]?
> 1: <>
> 2: <>
> In [2], it reads:
>         For patches that just add a new package, and a simple one, it’s
>         OK to commit, if you’re confident (which means you successfully
>         built it in a chroot setup, and have done a reasonable copyright
>         and license auditing). Likewise for package upgrades, except
>         upgrades that trigger a lot of rebuilds (for example, upgrading
>         GnuTLS or GLib).
> which I understand as: the ’staging’ or ’core-update’ patches should go
> to guix-patches and not be pushed directly.  Especially when one has
> commit access and does not follow closely enough to know the status of
> the very branch.

I don't think the quoted part fully answered it, but the following part
does answer it:

     Depending on the number of dependent packages and thus the amount
     of rebuilding induced, commits go to different branches, along
     these lines:

     300 dependent packages or less
          ‘master’ branch (non-disruptive changes).

     between 300 and 1,800 dependent packages
          ‘staging’ branch (non-disruptive changes).  This branch is
          intended to be merged in ‘master’ every 6 weeks or so.
          Topical changes (e.g., an update of the GNOME stack) can
          instead go to a specific branch (say, ‘gnome-updates’).

     more than 1,800 dependent packages
          ‘core-updates’ branch (may include major and potentially
          disruptive changes).  This branch is intended to be merged in
          ‘master’ every 6 months or so.

I guess I hadn't read that part of the manual.  Oops!  So it does seem
well answered.  Good!

 - Chris

reply via email to

[Prev in Thread] Current Thread [Next in Thread]