Since there seems to be agreement, I opened a ticket (CASSANDRA-17837) and a pull request (https://github.com/apache/cassandra/pull/1799) in so that the final text can be hashed out and accepted.
I also used the proposed pull request in the text of the pull so that it can be seen in all its glory 😇 On Thu, Aug 18, 2022 at 9:10 PM Josh McKenzie <jmcken...@apache.org> wrote: > 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. > > >
