It’s worth clarifying that CEP-10 has been broken up into phases, and this will be a roll-up branch for only the first portion.
I think we should be cautious about how we approach the idea of feature branches, as there is significant overhead for everyone as branches grow - the CEP-10 and CEP-14 work has had significant additional overhead introduced by this. There are also additional risks introduced during frequent or long term rebases, as they are hard to review. I think the idea is good, but ideally if feature development is expected to span more than a single quarter it would be best to target phased incorporation into mainline, and not defer everything to the final moment. I think it also helps focus review, testing, documentation etc. to have manageable chunks of work merged long before any perceived deadline. From: Jeremiah D Jordan <jeremiah.jor...@gmail.com> Date: Friday, 17 September 2021 at 20:50 To: Cassandra DEV <dev@cassandra.apache.org> Subject: Re: [DISCUSS] CASSANDRA-16922 CEP-10: Major Prerequisites (Phase 1) > As these progress through review, the aim is to roll them up into a single > branch and merge that to trunk together, keeping the separate commits for the > specific JIRAs. I think this is a great idea. Where do you see the “Roll Up Branch” living? Does the project want to start keeping long lived feature branches in the apache/cassandra repository? Or should the roll up branch still be kept in a fork? Caleb expressed interest in following this development model for SAI as well, and I think it makes sense for all of the larger CEPs to develop them in longer lived feature branches to be merged into trunk once they are complete. -Jeremiah > On Sep 17, 2021, at 1:52 PM, Sam Tunnicliffe <s...@beobal.com> wrote: > > This umbrella issue covers the major structural refactorings to enable the > higher level pieces of CEP-10. The current proposal is to post separate > patches for each JIRA to lessen the review burden as much as possible. > However, the patches are incremental, so there is a dependency from one to > the next. As these progress through review, the aim is to roll them up into a > single branch and merge that to trunk together, keeping the separate commits > for the specific JIRAs. > > These patches are not intended to introduce any significant new behaviour, > they're largely just introducing new abstractions to enable pieces of the > system to be swapped out when running simulations.These patches are > foundational to the CEP-10 work and so getting them landed is something of a > priority. They have been produced collaboratively by several committers, but > obviously further review and feedback is strongly encouraged. That said, > allocating requisite time and resources to such large and complex changesets > can be challenging, so we have a balance to strike. > > Whilst the 2 committer review requirement can technically be satisfied > already, it's reasonable to give fair warning and opportunity to contribute > before we start moving this forward. Notwithstanding that, there are some > failing tests still to address, mostly due to changes made in trunk since > this work was started and subsequently encountered during rebase. > > Thanks, > Sam > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
