I'd frame the reasoning differently: Our current merge strategy is vestigial and we can't rely on it in many, if not most, cases. Patches rarely merge cleanly across majors requiring -s ours w/amend or other changes per branch. This effectively clutters up our git history, hides multi-branch changes behind merge commits, makes in-IDE annotations less effective, and makes the barrier for reverting bad patches higher. It also just so happens to make it effectively impossible to use github actions to block merge on green CI.
On the positive side, it makes it much less likely we will forget to apply a bugfix patch on all branches, and it's the Devil we Know and the entire project understands and is relatively consistent with the current strategy. What other positives are there to the current merge strategy that I may not be thinking of? ~Josh On Tue, Dec 7, 2021 at 10:35 AM Brandon Williams <dri...@gmail.com> wrote: > On Tue, Dec 7, 2021 at 8:18 AM Joshua McKenzie <jmcken...@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"? If we make this change we'll be able to > > integrate w/github actions and block merge on green CI + integrate git > > revert into our processes. > > Changing the merge strategy can have deep and possibly unforeseen > consequences, if the only reasoning is "because github needs it to do > X" then that reasoning doesn't seem sound enough to me. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
