I think simple, consistent, reliable and unavoidable are *the* killer features for QA. All features (give or take) of the industry standard approach of using CI hooks to gate PR merge.
From: Joshua McKenzie <jmcken...@apache.org> Date: Wednesday, 5 January 2022 at 14:53 To: dev <dev@cassandra.apache.org> Subject: Re: [DISCUSS] Releasable trunk and quality 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<mailto:bened...@apache.org> <bened...@apache.org<mailto: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<mailto:bened...@apache.org> <bened...@apache.org<mailto:bened...@apache.org>> Date: Tuesday, 4 January 2022 at 23:52 To: David Capwell <dcapw...@apple.com<mailto:dcapw...@apple.com>>, Joshua McKenzie <jmcken...@apache.org<mailto:jmcken...@apache.org>> Cc: Henrik Ingo <henrik.i...@datastax.com<mailto:henrik.i...@datastax.com>>, dev <dev@cassandra.apache.org<mailto: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<mailto:dcapw...@apple.com>> Date: Tuesday, 4 January 2022 at 23:33 To: Joshua McKenzie <jmcken...@apache.org<mailto:jmcken...@apache.org>> Cc: Henrik Ingo <henrik.i...@datastax.com<mailto:henrik.i...@datastax.com>>, dev <dev@cassandra.apache.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:dev-unsubscr...@cassandra.apache.org> > For additional commands, e-mail: > dev-h...@cassandra.apache.org<mailto:dev-h...@cassandra.apache.org> > > -- Henrik Ingo +358 40 569 7354<tel:358405697354> [Visit us online.]<https://www.datastax.com/> [Visit us on Twitter.] <https://twitter.com/DataStaxEng> [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=> [Visit my LinkedIn profile.] <https://www.linkedin.com/in/heingo/>
