> It makes sense that such bug tickets are incentivised to be minimal, and if > there is a smarter way (improvement) in trunk that is a separate follow-up > ticket and patch
Are you proposing separating the work entirely, so that we don’t merge up to trunk at all, or do a no-op merge? Often things are done differently in trunk (and intervening branches) for a combination of reasons, including that the landscape has changed so that the earlier approach is inapplicable. Either way, what you are proposing sounds like introducing unnecessary additional work? > and that we have a more concise git history (one ~third the merge commits). Don’t we get a more concise history with the cherry-pick approach, since we don’t have any of the merge commits from each prior branch? Today, a merge commit from 2.2 will accumulate four merge commits on the way to trunk. My view: * Merge commits aren’t that useful * It is a bad idea to have a different CI pipeline for multi-version development * It is particularly not worth countenancing solely to retain the limited utility of merge commits From: Mick Semb Wever <m...@apache.org> Date: Sunday, 12 December 2021 at 11:47 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] Releasable trunk and quality > I find it cleaner that work is found associated to one sha on the hardest > > branch, and we treat (or should be) CI holistically across branches. > > If we -s ours and amend merge commits on things that straddle stuff like > 8099, MS rewrite, Simulator, guardrails, etc, then we have multiple SHA > where the impl for a thing took place and N of them (N being count of newer > branches than oldest where it applies) where they're hidden inside a merge > commit right? > That patches can be significantly different across branches is inavertible. One original commit versus individual commits on each branch is a trade-off between cleaner git history and github fancies with more direct commits. Taking it further, patches to release branches should be as minimal as possible. It makes sense that such bug tickets are incentivised to be minimal, and if there is a smarter way (improvement) in trunk that is a separate follow-up ticket and patch. So… I am willing to say (for now) that I like it that merge shas have the connection to the original singular shas on the hardest branch, and that we have a more concise git history (one ~third the merge commits). > Also, nothing's keeping us from treating CI holistically and pushing > --atomic across multiple branches even if we don't have merge commits. > That's just a procedural question we could agree on and adhere to. > Sure, but atomic is not the same: it's manual adherence and there's no history/record of it.
