Changes to the branching workflow

Changes to the branching workflow

[Leo Famulari]

Based on experiences with the last "staging" cycle and discussions at
the most recent Guix Day meeting [0], we've changed the branching
workflow.

The default branch names remain "core-updates" and "staging".

When we begin actively building and testing the branches, they will be
renamed to "core-updates-frozen" and "staging-frozen", respectively.

This will indicate that they are closed to any changes except for bug
fixes and merges of the master branch.

During those periods, new patches can be pushed to "core-updates-next"
and "staging-next".

Hopefully these changes will clarify the status of the branches and
reduce confusion.

[0] https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00163.html

Re: Changes to the branching workflow

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

Leo,

Almost perfect, thanks ;-)

Leo Famulari 写道：
> During those periods, new patches can be pushed to 
> "core-updates-next"
> and "staging-next".

I suggest just ‘branching’ staging & core-updates to a -frozen 
snapshot and keeping both staging & core-updates in a state of 
perpetual summer.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Changes to the branching workflow

[Leo Famulari]

On Fri, Feb 12, 2021 at 11:34:13AM +0100, Tobias Geerinckx-Rice wrote:
> Leo Famulari 写道：
> > During those periods, new patches can be pushed to "core-updates-next"
> > and "staging-next".
> 
> I suggest just ‘branching’ staging & core-updates to a -frozen snapshot and
> keeping both staging & core-updates in a state of perpetual summer.

I thought that the use of -frozen and -next might help avoid mistakes
during the active part of the cycles.

If someone wasn't aware of the branch status, the lack of a
'core-updates' branch might make them think twice and ask for advice.

Re: Changes to the branching workflow

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

Hi Leo!

Leo Famulari 写道：
> I thought that the use of -frozen and -next might help avoid 
> mistakes
> during the active part of the cycles.

Ah, there's my blind spot.  What kinds of mistakes?  When is it 
harmful to push to the open branch?

I say ‘the open branch’ because core-updates and core-updates-next 
are the same thing, constantly changing its name in perfect 
(manual!) sync with -frozen & I don't understand why (yet).  Seems 
obscure & error prone.

> If someone wasn't aware of the branch status, the lack of a
> 'core-updates' branch might make them think twice and ask for 
> advice.

I think they'll push and create a third one.  I won't blame them.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Changes to the branching workflow

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 617 bytes --]

On Fri, Feb 12, 2021 at 08:34:34PM +0100, Tobias Geerinckx-Rice wrote:
> Ah, there's my blind spot.  What kinds of mistakes?  When is it harmful to
> push to the open branch?

Mistakes caused by lack of communication about the status of the
branches.

During the recent staging cycle, people kept pushing patches to the
branch after it was frozen.

After the recent staging cycle, before staging-next was renamed to
staging, people pushed changes to a new staging branch, ignoring the
staging-next branch. I had to clean that up.

What do you think? Should we stick with the plan I wrote in the manual?
Or change it?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Changes to the branching workflow

[Andreas Enge]

Am Fri, Feb 12, 2021 at 03:17:34PM -0500 schrieb Leo Famulari:
> What do you think? Should we stick with the plan I wrote in the manual?
> Or change it?

From what I understood of the discussion, I would also go with Tobias's and
Efraim's suggestion: There is a core-updates branch that is constantly open
and where people can push; this does not seem to leave a possibility of
mistake, almost by definition. Then we can branch off core-updates-frozen,
which is frozen :), except for cherry-picked bug fixing commits and merges
from master. Once it is finished, it is merged into master and deleted.

The one thing where maybe problems can occur is that now there is the
core-updates branch that has wildly advanced, and that needs to somehow be
tamed to go with the new master branch. But the situation would be the same
if it were called core-updates-next, I suppose.

Technically speaking, this is the same as your suggestion, Leo, but it
avoids the constant dance between core-updates, that disappears and
reappears under the name core-updates-next, that disappears and reappears
under the name core-updates, and so on.

Andreas

Re: Changes to the branching workflow

[Hartmut Goebel]

Am 11.02.21 um 23:42 schrieb Leo Famulari:
> The default branch names remain "core-updates" and "staging".
>
> […]
>
> During those periods, new patches can be pushed to "core-updates-next"
> and "staging-next".

What should be the use of these *-next branches. I can't see any except 
confusing committers. Why can't on push to staging and core-update 
during the active part of the cycle?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Changes to the branching workflow

[Hartmut Goebel]

Am 12.02.21 um 21:49 schrieb Andreas Enge:
>  From what I understood of the discussion, I would also go with Tobias's and
> Efraim's suggestion: There is a core-updates branch that is constantly open
> and where people can push; this does not seem to leave a possibility of
> mistake, almost by definition. Then we can branch off core-updates-frozen,
> which is frozen :), except for cherry-picked bug fixing commits and merges
> from master. Once it is finished, it is merged into master and deleted.

This is what I understood, too.

> Technically speaking, this is the same as your suggestion, Leo, but it
> avoids the constant dance between core-updates, that disappears and
> reappears under the name core-updates-next, that disappears and reappears
> under the name core-updates, and so on.
It's even worse: When removing staging and core-updates at Savannah, 
this does not effect local copies. Thus one might push these branches to 
Savannah, which might lead to a lot of confusion and trouble.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Changes to the branching workflow

[Leo Famulari]

On Sat, Feb 13, 2021 at 12:24:50PM +0100, Hartmut Goebel wrote:
> Am 12.02.21 um 21:49 schrieb Andreas Enge:
> >  From what I understood of the discussion, I would also go with Tobias's and
> > Efraim's suggestion: There is a core-updates branch that is constantly open
> > and where people can push; this does not seem to leave a possibility of
> > mistake, almost by definition. Then we can branch off core-updates-frozen,
> > which is frozen :), except for cherry-picked bug fixing commits and merges
> > from master. Once it is finished, it is merged into master and deleted.
> 
> This is what I understood, too.
> 
> > Technically speaking, this is the same as your suggestion, Leo, but it
> > avoids the constant dance between core-updates, that disappears and
> > reappears under the name core-updates-next, that disappears and reappears
> > under the name core-updates, and so on.
> It's even worse: When removing staging and core-updates at Savannah, this
> does not effect local copies. Thus one might push these branches to
> Savannah, which might lead to a lot of confusion and trouble.

Alright.

Due to overwhelming demand both on and off list, the bikeshed has been
repainted.

Re: Changes to the branching workflow

[Tobias Geerinckx-Rice]

Leo,

On 2021-02-13 19:21, Leo Famulari wrote:
> Due to overwhelming demand both on and off list, the bikeshed has been
> repainted.

...and the second-floor window (it's... a big shed?) no longer reads 
'Way Out ->'.

One can trivialise anything.

Genuine thanks for pushing for improvement,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

Re: Changes to the branching workflow

[Christopher Lemmer Webber]

Hello,

As someone who jumps in and out of Guix development occasionally but who
does have commit access (probably for grantparented-in reasons, heh),
sometimes I don't know where I should commit code or what the current
branching policy is, and I might miss emails like this.

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?

I think that would help me, and maybe it would help others.  Thoughts?

 - Chris

Leo Famulari writes:

> Based on experiences with the last "staging" cycle and discussions at
> the most recent Guix Day meeting [0], we've changed the branching
> workflow.
>
> The default branch names remain "core-updates" and "staging".
>
> When we begin actively building and testing the branches, they will be
> renamed to "core-updates-frozen" and "staging-frozen", respectively.
>
> This will indicate that they are closed to any changes except for bug
> fixes and merges of the master branch.
>
> During those periods, new patches can be pushed to "core-updates-next"
> and "staging-next".
>
> Hopefully these changes will clarify the status of the branches and
> reduce confusion.
>
> [0] https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00163.html

Re: Changes to the branching workflow

[zimoun]

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.


Cheers,
simon

Re: Changes to the branching workflow

[Christopher Lemmer Webber]

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

Re: Changes to the branching workflow

[zimoun]

Hi Chris,

On Fri, 05 Mar 2021 at 10:34, Christopher Lemmer Webber <cwebber@dustycloud.org> wrote:
> zimoun writes:
>> 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:

Point #8 in [1] answered to «explaining what the different branches».
And because it was hard to refer a specific part of [2], hence the
quote, to answer to: «when you have a patch that's been approved, when to
push it to which branch?», especially to know the status of the branch.

Sorry if I have been unclear.


Cheers,
simon