* Changes to the branching workflow @ 2021-02-11 22:42 Leo Famulari 2021-02-12 10:34 ` Tobias Geerinckx-Rice ` (2 more replies) 0 siblings, 3 replies; 14+ 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] 14+ 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 2021-03-04 21:05 ` Christopher Lemmer Webber 2 siblings, 1 reply; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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 2021-03-04 21:05 ` Christopher Lemmer Webber 2 siblings, 0 replies; 14+ 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] 14+ 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 @ 2021-03-04 21:05 ` Christopher Lemmer Webber 2021-03-04 22:01 ` zimoun 2 siblings, 1 reply; 14+ messages in thread From: Christopher Lemmer Webber @ 2021-03-04 21:05 UTC (permalink / raw) To: Leo Famulari; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Changes to the branching workflow 2021-03-04 21:05 ` Christopher Lemmer Webber @ 2021-03-04 22:01 ` zimoun 2021-03-05 15:34 ` Christopher Lemmer Webber 0 siblings, 1 reply; 14+ messages in thread From: zimoun @ 2021-03-04 22:01 UTC (permalink / raw) To: Christopher Lemmer Webber, Leo Famulari; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Changes to the branching workflow 2021-03-04 22:01 ` zimoun @ 2021-03-05 15:34 ` Christopher Lemmer Webber 2021-03-05 15:52 ` zimoun 0 siblings, 1 reply; 14+ messages in thread From: Christopher Lemmer Webber @ 2021-03-05 15:34 UTC (permalink / raw) To: zimoun; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Changes to the branching workflow 2021-03-05 15:34 ` Christopher Lemmer Webber @ 2021-03-05 15:52 ` zimoun 0 siblings, 0 replies; 14+ messages in thread From: zimoun @ 2021-03-05 15:52 UTC (permalink / raw) To: Christopher Lemmer Webber; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-03-05 15:59 UTC | newest] Thread overview: 14+ 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 2021-03-04 21:05 ` Christopher Lemmer Webber 2021-03-04 22:01 ` zimoun 2021-03-05 15:34 ` Christopher Lemmer Webber 2021-03-05 15:52 ` zimoun
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).