Does this work with trunk patches that involve other branches as well? I’d imagine we have the same problem. Or are we proposing limiting this feature to trunk _only_ patches? If so, that seems rather weak.
From: Brandon Williams <dri...@gmail.com> Date: Thursday, 9 December 2021 at 20:25 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] Releasable trunk and quality +1 to trying trunk first. On Thu, Dec 9, 2021 at 1:52 PM 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)… --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
