The benefits being extolled involve people setting up GitHub bots to integrate with PRs to run CI etc, which will require some non-trivial investment by somebody to put together
The alternative merge strategy being discussed is not to merge, but to instead cherry-pick or rebase. This means we can produce separate PRs for each branch, that can be merged independently via the GitHub API. The downside of this is that there are no merge commits, while one upside of this is that there are no merge commits. > On 18 Aug 2022, at 20:20, Stefan Miklosovic > <stefan.mikloso...@instaclustr.com> wrote: > > No chicken-egg to me. All it takes is ctrl+c & ctrl+v on your merging > commits. How would new merging strategy actually look like? I am all > ears. This seems to be quite nice as is if we stick to be more verbose > what we did. > >> On Thu, 18 Aug 2022 at 20:27, Benedict <bened...@apache.org> wrote: >> >> Was it? >> >> I mean, we’ve all (or most) I think worked on projects with those things, so >> we all know what the benefits are? >> >> It’s fair to point out that we don’t have it even running for any branch >> yet. However there’s perhaps a chicken-and-egg situation, where I’m unsure >> the investment to develop can be justified by those who are able, if there’s >> a chance it will be discarded? I can’t see us maintaining a bifurcated >> process, where some patches go through automation and others don’t, so if we >> don’t change the merge strategy that work would presumably end up wasted. >> >> On 18 Aug 2022, at 18:53, Mick Semb Wever <m...@apache.org> wrote: >> >> >>> >>> That debatable benefit aside, not doing merge commits would also open up >>> options for us to use PR's for merges and integrate running CI, and >>> blocking on clean CI, pre-merge. Which has some other pretty big benefits. >>> :) >> >> >> >> The past agreement IIRC was to start doing those things on trunk-only so we >> can evaluate them for real.
