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.
