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

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

[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