Re: Changes to the branching workflow

[Christopher Lemmer Webber <cwebber@dustycloud.org>]

zimoun writes:

> Hi, Chris,
>
> On Thu, 04 Mar 2021 at 16:05, Christopher Lemmer Webber <cwebber@dustycloud.org> 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: <https://guix.gnu.org/manual/en/guix.html#Submitting-Patches>
> 2: <https://guix.gnu.org/manual/en/guix.html#Commit-Access>
>
> 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