+1 on Mick’s suggestion (nb)
On Thu, 9 Dec 2021 at 14:46, Mick Semb Wever <m...@apache.org> wrote: > > > > So let me pose the question here to the list: is there anyone who would > > like to advocate for the current merge strategy (apply to oldest LTS, > merge > > up, often -s ours w/new patch applied + amend) instead of "apply to trunk > > and cherry-pick back to LTS"? > > > > I'm in favour of the current merge strategy. > I find it cleaner that work is found associated to one sha on the hardest > branch, and we treat (or should be) CI holistically across branches. > I can appreciate that github makes some things easier, but I suspect it > will make other things messier and that there will be other consequences. > > My understanding was that we would first introduce such github fancies on > only commits that are intended for trunk. I am in favour of taking that > approach, changing our merge strategy can happen later, once we have ironed > out how the github/CI/stable-trunk is working best for us. I think this > would also help us understand more about the impacts of changing the merge > strategy. > > I was also under the impression that we are now aiming to be committing > less to the release branches. That means changing the merge strategy is of > less importance (and that there is benefit to keeping it as-is). Certainly > the commits on past branches seems very low at the moment, considering many > users are on 4.0, and this is a trend we want to continue. > > My opinion, let's take this in two steps (try stuff on just trunk first)… >
