[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
> <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