Re: Managing patches and branches, retrospective and futher changes?
Andreas Enge 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. signature.asc Description: PGP signature
Re: Managing patches and branches, retrospective and futher changes?
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?
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 רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Managing patches and branches, retrospective and futher changes?
Steve George 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 signature.asc Description: PGP signature
Re: Managing patches and branches, retrospective and futher changes?
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
