Managing patches and branches, retrospective and futher changes?

Managing patches and branches, retrospective and futher changes?

[Christopher Baines]

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

Re: Managing patches and branches, retrospective and futher changes?

[Steve George]

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

[bug#70549] Managing patches and branches, retrospective and futher changes?

[Christopher Baines]

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

Re: Managing patches and branches, retrospective and futher changes?

[Efraim Flashner]

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

[bug#70549] Managing patches and branches, retrospective and futher changes?

[Andreas Enge]

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

Re: Managing patches and branches, retrospective and futher changes?

[Christopher Baines]

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