> I have never seen this > kind of git merging strategy elsewhere, I am not sure if I am not > experienced enough or we are truly unique the way we do things. I am very fond of this project and this community. THAT SAID ;) you could replace "kind of git merging strategy" with a lot of different things and have it equally apply on this project.
Perils of being a mature long-lived project I suspect. I'm all for us doing the hard work of introspecting on how we do things and changing them to improve or match industry standards where applicable. On Thu, Aug 18, 2022, at 3:33 PM, Stefan Miklosovic wrote: > Interesting, thanks for explicitly writing that down. I humbly think > the CI and the convenience of the GitHub workflow is ultimately > secondary when it comes to the code-base as such. Indeed, nice to > have, but if it turns out to be uncomfortable in other ways, I guess > we just have to live with what we have. TBH I have never seen this > kind of git merging strategy elsewhere, I am not sure if I am not > experienced enough or we are truly unique the way we do things. > However, it does make sense. > > On Thu, 18 Aug 2022 at 21:28, Benedict <benedictatapa...@icloud.com> wrote: > > > > 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. >
