A wise man once said "Simple is a feature" ;) Our current process (commit oldest, merge up or merge -s ours w/ --amend): - is confusing for new contributors to understand - hides changes inside the merge commit - masks future ability to see things with git attribute on commits - is exposed to race w/other committers across multiple branches requiring --atomic - is non-automatable requiring human intervention and prone to error - prevents us from using industry standard tooling and workflows around CI thus contributing to CI degrading over time + Helps enforce that we don't forget to apply something to all branches +(?) Is the devil we know
That's a lot of negatives for a very fixable single positive and some FUD. On Tue, Jan 4, 2022 at 7:01 PM bened...@apache.org <bened...@apache.org> wrote: > To answer your point, I don’t have anything ideologically against a > temporary divergence in treatment, but we should have a clear unified > endpoint we are aiming for. > > > > I would hate for this discussion to end without a clear answer about what > that endpoint should be, though - even if we don’t get there immediately. > > > > I personally dislike the idea of relying on scripts to enforce this, at > least in the long run, as there is no uniformity of environment, so no > uniformity of process, and when things go wrong due to diverging systems > we’re creating additional work for people (and CI is headache enough when > it goes wrong). > > > > > > *From: *bened...@apache.org <bened...@apache.org> > *Date: *Tuesday, 4 January 2022 at 23:52 > *To: *David Capwell <dcapw...@apple.com>, Joshua McKenzie < > jmcken...@apache.org> > *Cc: *Henrik Ingo <henrik.i...@datastax.com>, dev < > dev@cassandra.apache.org> > *Subject: *Re: [DISCUSS] Releasable trunk and quality > > That all sounds terribly complicated to me. > > > > My view is that we should switch to the branch strategy outlined by Henrik > (I happen to prefer it anyway) and move to GitHub integrations to control > merge for each branch independently. Simples. > > > > > > *From: *David Capwell <dcapw...@apple.com> > *Date: *Tuesday, 4 January 2022 at 23:33 > *To: *Joshua McKenzie <jmcken...@apache.org> > *Cc: *Henrik Ingo <henrik.i...@datastax.com>, dev < > dev@cassandra.apache.org> > *Subject: *Re: [DISCUSS] Releasable trunk and quality > > The more I think on it, the more I am anyway strongly -1 on having some > bifurcated commit process. We should decide on a uniform commit process for > the whole project, for all patches, whatever that may be. > > > > Making the process stable and handle all the random things we need to > handle takes a lot of time, for that reason I strongly feel we should start > with trunk only and look to expand to other branches and/or handle > multi-branch commits. I agree that each branch should NOT have a different > process, but feel its ok if we are evolving what the process should be. > > > > About the merge commit thing, we can automate (think Josh wants to OSS my > script) the current process so this isn’t a blocker for automation; the > thing I hate about it is that I have not found any tool able to understand > our history, so it forces me to go to CLI to figure out how the merge > actually changed things (only the smallest version can be displayed > properly), I am 100% in favor of removing, but don’t think its a dependency > on automating our merge process. > > > > > > > On Jan 4, 2022, at 11:58 AM, Joshua McKenzie <jmcken...@apache.org> wrote: > > > > I put together a draft confluence wiki page (login required) for the Build > Lead role covering what we discussed in the thread here. Link: > https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=199527692&draftShareId=96dfa1ef-d927-427a-bff8-0cf711c790c9&; > > > > The only potentially controversial thing in there is text under what to do > with a consistent test failure introduced by a diff to trunk: "If > consistent, *git revert* *the SHA that introduced the failure*, re-open > the original JIRA ticket, and leave a note for the original assignee about > the breakage they introduced". > > > > This would apply only to patches to trunk that introduce consistent > failures to a test clearly attributable to that patch. > > > > I am deferring on the topic of merge strategy as there's a lot of progress > we can make without considering that more controversial topic yet. > > > > On Tue, Dec 21, 2021 at 9:02 AM Henrik Ingo <henrik.i...@datastax.com> > wrote: > > FWIW, I thought I could link to an example MongoDB commit: > > > > > https://github.com/mongodb/mongo/commit/dec388494b652488259072cf61fd987af3fa8470 > > > > * Fixes start from trunk or whatever is the highest version that includes > the bug > > * It is then cherry picked to each stable version that needs to fix. Above > link is an example of such a cherry pick. The original sha is referenced in > the commit message. > > * I found that it makes sense to always cherry pick from the immediate > higher version, since if you had to make some changes to the previous > commit, they probably need to be in the next one as well. > > * There are no merge commits. Everything is always cherry picked or > rebased to the top of a branch. > > * Since this was mentioned, MongoDB indeed tracks the cherry picking > process explicitly: The original SERVER ticket is closed when fix is > committed to trunk branch. However, new BACKPORT tickets are created and > linked to the SERVER ticket, one per stable version that will need a > cherry-pick. This way backporting the fix is never forgotten, as the team > can just track open BACKPRT tickets and work on them to close them. > > > > henrik > > > > On Tue, Dec 14, 2021 at 8:53 PM Joshua McKenzie <jmcken...@apache.org> > wrote: > > > > > I like a change originating from just one commit, and having tracking > > visible across the branches. This gives you immediate information about > > where and how the change was applied without having to go to the jira > > ticket (and relying on it being accurate) > > I have the exact opposite experience right now (though this may be a > shortcoming of my env / workflow). When I'm showing annotations in intellij > and I see walls of merge commits as commit messages and have to bounce over > to a terminal or open the git panel to figure out what actual commit on a > different branch contains the minimal commit message pointing to the JIRA > to go to the PR and actually finally find out _why_ we did a thing, then > dig around to see if we changed the impl inside a merge commit SHA from the > original base impl... > > Well, that is not my favorite. :D > > All ears on if there's a cleaner way to do the archaeology here. > > > On Tue, Dec 14, 2021 at 1:34 PM Stefan Miklosovic < > stefan.mikloso...@instaclustr.com> wrote: > > > Does somebody else use the git workflow we do as of now in Apache > > universe? Are not we quite unique? While I do share the same opinion > > Mick has in his last response, I also see the disadvantage in having > > the commit history polluted by merges. I am genuinely curious if there > > is any other Apache project out there doing things same we do (or did > > in the past) and who changed that in one way or the other, plus > > reasons behind it. > > > > On Tue, 14 Dec 2021 at 19:27, Mick Semb Wever <m...@apache.org> wrote: > > > > > > > > > > > > > > > > Merge commits aren’t that useful > > > > > > > > > I keep coming back to this. Arguably the only benefit they offer now > is > > > > procedurally forcing us to not miss a bugfix on a branch, but given > how > > > > much we amend many things presently anyway that dilutes that benefit. > > > > > > > > > > > > > Doesn't this come down to how you read git history, and for example > > > appreciating a change-centric view over branch isolated development? > > > I like a change originating from just one commit, and having tracking > > > visible across the branches. This gives you immediate information about > > > where and how the change was applied without having to go to the jira > > > ticket (and relying on it being accurate). Connecting commits on > > different > > > branches that are developed separately (no merge tracking) is more > > > complicated. So yeah, I see value in those merge commits. I'm not > against > > > trying something new, just would appreciate a bit more exposure to it > > > before making a project wide change. Hence, let's not rush it and just > > > start first with trunk. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > -- > > Henrik Ingo > > +358 40 569 7354 <358405697354> > > [image: Visit us online.] <https://www.datastax.com/> [image: Visit us > on Twitter.] <https://twitter.com/DataStaxEng> [image: Visit us on > YouTube.] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_channel_UCqA6zOSMpQ55vvguq4Y0jAg&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=bmIfaie9O3fWJAu6lESvWj3HajV4VFwgwgVuKmxKZmE&s=16sY48_kvIb7sRQORknZrr3V8iLTfemFKbMVNZhdwgw&e=> > [image: Visit my LinkedIn profile.] > <https://www.linkedin.com/in/heingo/> > > >
