> > limiting this feature to trunk _only_ patches? If so, that seems rather > weak.
It's definitely a weaker guarantee. On the plus side, if we're doing bugfix only to all released branches and limiting improvements and new features to trunk, in theory those will be the more disruptive patches that are more likely to break CI. Possibly. On Thu, Dec 9, 2021 at 5:35 PM bened...@apache.org <bened...@apache.org> wrote: > 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 >
