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/> >
