> A wise man once said "Simple is a feature" ;) For those unfamiliar, this was a reference to a sentiment Jonathan has expressed over the years which I strongly agree with https://issues.apache.org/jira/browse/CASSANDRA-6809?focusedCommentId=14102901&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14102901
On Wed, Jan 5, 2022 at 9:52 AM Joshua McKenzie <jmcken...@apache.org> wrote: > 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/> >> >> >> >
