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.
