Good with all the above (reasonable arguments) except I don't understand: > > 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.
If we -s ours and amend merge commits on things that straddle stuff like 8099, MS rewrite, Simulator, guardrails, etc, then we have multiple SHA where the impl for a thing took place and N of them (N being count of newer branches than oldest where it applies) where they're hidden inside a merge commit right? Also, nothing's keeping us from treating CI holistically and pushing --atomic across multiple branches even if we don't have merge commits. That's just a procedural question we could agree on and adhere to. On Thu, Dec 9, 2021 at 3:25 PM Brandon Williams <dri...@gmail.com> wrote: > +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 > >
