unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / Atom feed
* Changes to the branching workflow
@ 2021-02-11 22:42 Leo Famulari
  2021-02-12 10:34 ` Tobias Geerinckx-Rice
  2021-02-13 11:19 ` Hartmut Goebel
  0 siblings, 2 replies; 10+ messages in thread
From: Leo Famulari @ 2021-02-11 22:42 UTC (permalink / raw)
  To: guix-devel

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Changes to the branching workflow
  2021-02-11 22:42 Changes to the branching workflow Leo Famulari
@ 2021-02-12 10:34 ` Tobias Geerinckx-Rice
  2021-02-12 18:01   ` Leo Famulari
  2021-02-13 11:19 ` Hartmut Goebel
  1 sibling, 1 reply; 10+ messages in thread
From: Tobias Geerinckx-Rice @ 2021-02-12 10:34 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Changes to the branching workflow
  2021-02-12 10:34 ` Tobias Geerinckx-Rice
@ 2021-02-12 18:01   ` Leo Famulari
  2021-02-12 19:34     ` Tobias Geerinckx-Rice
  0 siblings, 1 reply; 10+ messages in thread
From: Leo Famulari @ 2021-02-12 18:01 UTC (permalink / raw)
  To: Tobias Geerinckx-Rice; +Cc: guix-devel

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.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Changes to the branching workflow
  2021-02-12 18:01   ` Leo Famulari
@ 2021-02-12 19:34     ` Tobias Geerinckx-Rice
  2021-02-12 20:17       ` Leo Famulari
  0 siblings, 1 reply; 10+ messages in thread
From: Tobias Geerinckx-Rice @ 2021-02-12 19:34 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Changes to the branching workflow
  2021-02-12 19:34     ` Tobias Geerinckx-Rice
@ 2021-02-12 20:17       ` Leo Famulari
  2021-02-12 20:49         ` Andreas Enge
  0 siblings, 1 reply; 10+ messages in thread
From: Leo Famulari @ 2021-02-12 20:17 UTC (permalink / raw)
  To: Tobias Geerinckx-Rice; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Changes to the branching workflow
  2021-02-12 20:17       ` Leo Famulari
@ 2021-02-12 20:49         ` Andreas Enge
  2021-02-13 11:24           ` Hartmut Goebel
  0 siblings, 1 reply; 10+ messages in thread
From: Andreas Enge @ 2021-02-12 20:49 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Changes to the branching workflow
  2021-02-11 22:42 Changes to the branching workflow Leo Famulari
  2021-02-12 10:34 ` Tobias Geerinckx-Rice
@ 2021-02-13 11:19 ` Hartmut Goebel
  1 sibling, 0 replies; 10+ messages in thread
From: Hartmut Goebel @ 2021-02-13 11:19 UTC (permalink / raw)
  To: guix-devel

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 |



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Changes to the branching workflow
  2021-02-12 20:49         ` Andreas Enge
@ 2021-02-13 11:24           ` Hartmut Goebel
  2021-02-13 18:21             ` Leo Famulari
  0 siblings, 1 reply; 10+ messages in thread
From: Hartmut Goebel @ 2021-02-13 11:24 UTC (permalink / raw)
  To: guix-devel

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 |



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Changes to the branching workflow
  2021-02-13 11:24           ` Hartmut Goebel
@ 2021-02-13 18:21             ` Leo Famulari
  2021-02-13 19:40               ` Tobias Geerinckx-Rice
  0 siblings, 1 reply; 10+ messages in thread
From: Leo Famulari @ 2021-02-13 18:21 UTC (permalink / raw)
  To: Hartmut Goebel; +Cc: guix-devel

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.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Changes to the branching workflow
  2021-02-13 18:21             ` Leo Famulari
@ 2021-02-13 19:40               ` Tobias Geerinckx-Rice
  0 siblings, 0 replies; 10+ messages in thread
From: Tobias Geerinckx-Rice @ 2021-02-13 19:40 UTC (permalink / raw)
  To: Leo Famulari; +Cc: Hartmut Goebel, guix-devel

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.


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-02-13 19:40 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-11 22:42 Changes to the branching workflow Leo Famulari
2021-02-12 10:34 ` Tobias Geerinckx-Rice
2021-02-12 18:01   ` Leo Famulari
2021-02-12 19:34     ` Tobias Geerinckx-Rice
2021-02-12 20:17       ` Leo Famulari
2021-02-12 20:49         ` Andreas Enge
2021-02-13 11:24           ` Hartmut Goebel
2021-02-13 18:21             ` Leo Famulari
2021-02-13 19:40               ` Tobias Geerinckx-Rice
2021-02-13 11:19 ` Hartmut Goebel

unofficial mirror of guix-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git