unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Managing patches and branches, retrospective and futher changes?
@ 2024-04-24 13:21 Christopher Baines
  2024-04-25  7:29 ` Steve George
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Christopher Baines @ 2024-04-24 13:21 UTC (permalink / raw)
  To: guix-devel, 70549

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

Hey!

Almost a year ago, the branching strategy was changed [1][2].

1: https://issues.guix.gnu.org/63459
2: https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00024.html

I think these changes have gone OK, we've had ~27 [3] branches merged in
this manor and I think looking back these changes have been
helpful. Coordination and visibility has improved, and we've been able
to build and test more prior to merging.

3: https://issues.guix.gnu.org/search?query=%22Request+for+merging%22

There's still room for more improvement though. The current guidance is
here [4], and I've sent a patch for improvements here [5].

4: https://guix.gnu.org/en/manual/devel/en/html_node/Managing-Patches-and-Branches.html
5: https://issues.guix.gnu.org/70549

Let me know if you have any thoughts or questions!

Thanks,

Chris

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

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

* Re: Managing patches and branches, retrospective and futher changes?
  2024-04-24 13:21 Managing patches and branches, retrospective and futher changes? Christopher Baines
@ 2024-04-25  7:29 ` Steve George
  2024-04-25 18:28   ` [bug#70549] " Christopher Baines
  2024-04-26 16:03 ` Efraim Flashner
  2024-04-29 13:24 ` [bug#70549] " Andreas Enge
  2 siblings, 1 reply; 6+ messages in thread
From: Steve George @ 2024-04-25  7:29 UTC (permalink / raw)
  To: Christopher Baines; +Cc: guix-devel, 70549

Hi,

I think we should strongly recommend against long-running unmerged branches.

Perhaps there could be a recommendation to merge every 3 months.

Could we add any automation to remind people if:

1. a branch has been unmerged for more than 3 months
2. an odd merge takes places (e.g. the core-updates merges)

Thanks,

Steve

On 24 Apr, Christopher Baines wrote:
> Hey!
> 
> Almost a year ago, the branching strategy was changed [1][2].
> 
> 1: https://issues.guix.gnu.org/63459
> 2: https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00024.html
> 
> I think these changes have gone OK, we've had ~27 [3] branches merged in
> this manor and I think looking back these changes have been
> helpful. Coordination and visibility has improved, and we've been able
> to build and test more prior to merging.
> 
> 3: https://issues.guix.gnu.org/search?query=%22Request+for+merging%22
> 
> There's still room for more improvement though. The current guidance is
> here [4], and I've sent a patch for improvements here [5].
> 
> 4: https://guix.gnu.org/en/manual/devel/en/html_node/Managing-Patches-and-Branches.html
> 5: https://issues.guix.gnu.org/70549
> 
> Let me know if you have any thoughts or questions!
> 
> Thanks,
> 
> Chris




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

* [bug#70549] Managing patches and branches, retrospective and futher changes?
  2024-04-25  7:29 ` Steve George
@ 2024-04-25 18:28   ` Christopher Baines
  0 siblings, 0 replies; 6+ messages in thread
From: Christopher Baines @ 2024-04-25 18:28 UTC (permalink / raw)
  To: Steve George; +Cc: guix-devel, 70549

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

Steve George <steve@futurile.net> writes:

> I think we should strongly recommend against long-running unmerged branches.
>
> Perhaps there could be a recommendation to merge every 3 months.

My hope is that with these process changes, we won't end up with
long-running branches.

Maybe we could add a recommendation, but I'm not really sure if that
would help. We still want to merge these changes when they and related
things are ready, so it's not really something that can be willed or
commanded to happen.

> Could we add any automation to remind people if:
>
> 1. a branch has been unmerged for more than 3 months

We can have QA highlight how long the issues have been open for, that's
quite easy to do.

> 2. an odd merge takes places (e.g. the core-updates merges)

I'm not quite sure what you mean here?

Thanks,

Chris

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

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

* Re: Managing patches and branches, retrospective and futher changes?
  2024-04-24 13:21 Managing patches and branches, retrospective and futher changes? Christopher Baines
  2024-04-25  7:29 ` Steve George
@ 2024-04-26 16:03 ` Efraim Flashner
  2024-04-29 13:24 ` [bug#70549] " Andreas Enge
  2 siblings, 0 replies; 6+ messages in thread
From: Efraim Flashner @ 2024-04-26 16:03 UTC (permalink / raw)
  To: Christopher Baines; +Cc: guix-devel, 70549

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

On Wed, Apr 24, 2024 at 02:21:56PM +0100, Christopher Baines wrote:
> Hey!
> 
> Almost a year ago, the branching strategy was changed [1][2].
> 
> 1: https://issues.guix.gnu.org/63459
> 2: https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00024.html
> 
> I think these changes have gone OK, we've had ~27 [3] branches merged in
> this manor and I think looking back these changes have been
> helpful. Coordination and visibility has improved, and we've been able
> to build and test more prior to merging.

I'd like to just say that this (without checking the numbers) is almost
10x the number of merges we had previously with just the
core-updates/staging branch strategy.

> 3: https://issues.guix.gnu.org/search?query=%22Request+for+merging%22
> 
> There's still room for more improvement though. The current guidance is
> here [4], and I've sent a patch for improvements here [5].
> 
> 4: https://guix.gnu.org/en/manual/devel/en/html_node/Managing-Patches-and-Branches.html
> 5: https://issues.guix.gnu.org/70549
> 
> Let me know if you have any thoughts or questions!
> 
> Thanks,
> 
> Chris



-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

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

* [bug#70549] Managing patches and branches, retrospective and futher changes?
  2024-04-24 13:21 Managing patches and branches, retrospective and futher changes? Christopher Baines
  2024-04-25  7:29 ` Steve George
  2024-04-26 16:03 ` Efraim Flashner
@ 2024-04-29 13:24 ` Andreas Enge
  2024-04-29 14:42   ` Christopher Baines
  2 siblings, 1 reply; 6+ messages in thread
From: Andreas Enge @ 2024-04-29 13:24 UTC (permalink / raw)
  To: Christopher Baines; +Cc: guix-devel, 70549

Hello,

Am Wed, Apr 24, 2024 at 02:21:56PM +0100 schrieb Christopher Baines:
> Let me know if you have any thoughts or questions!

in this part:
+@item
+Minimise the changes on master that are missing on the branch prior to
+merging the branch in to master.  Merging master in to the branch can be
+appropriate for this purpose.

I would drop the second sentence. It mildly contradicts the previous
"avoid merging master into the branch". Writing "avoid merging" instead
of "never merge" already allows for some leeway, I would prefer not to
insist on it.

Andreas





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

* Re: Managing patches and branches, retrospective and futher changes?
  2024-04-29 13:24 ` [bug#70549] " Andreas Enge
@ 2024-04-29 14:42   ` Christopher Baines
  0 siblings, 0 replies; 6+ messages in thread
From: Christopher Baines @ 2024-04-29 14:42 UTC (permalink / raw)
  To: Andreas Enge; +Cc: guix-devel, 70549

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

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> Am Wed, Apr 24, 2024 at 02:21:56PM +0100 schrieb Christopher Baines:
>> Let me know if you have any thoughts or questions!
>
> in this part:
> +@item
> +Minimise the changes on master that are missing on the branch prior to
> +merging the branch in to master.  Merging master in to the branch can be
> +appropriate for this purpose.
>
> I would drop the second sentence. It mildly contradicts the previous
> "avoid merging master into the branch". Writing "avoid merging" instead
> of "never merge" already allows for some leeway, I would prefer not to
> insist on it.

Yeah, maybe it's redundant. I think what I was trying to say is that
minimising the changes against master is a priority, so do this even if
you resort to merging master in to the branch.

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

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

end of thread, other threads:[~2024-04-29 14:42 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-24 13:21 Managing patches and branches, retrospective and futher changes? Christopher Baines
2024-04-25  7:29 ` Steve George
2024-04-25 18:28   ` [bug#70549] " Christopher Baines
2024-04-26 16:03 ` Efraim Flashner
2024-04-29 13:24 ` [bug#70549] " Andreas Enge
2024-04-29 14:42   ` Christopher Baines

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).