> > 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)…
