Hi everyone, Just wanted to send out a final call before I start merging Phase 1 of CEP-10. If somebody is keen to get involved pipe up here - more than happy to defer commit in order to collaborate or discuss the improvements further. Otherwise I plan to start committing Phase 1 of CEP-10 this week, starting with 16923 and 16924, moving on to 16925 and 16926 next week.
Note that patches for the later phases are being posted now as well, with the Simulator itself to follow this week. From: Joshua McKenzie <jmcken...@apache.org> Date: Friday, 17 September 2021 at 22:08 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] CASSANDRA-16922 CEP-10: Major Prerequisites (Phase 1) > > ideally if feature development is expected to span more than a single > quarter it would be best to target phased incorporation into mainline Strong +1 here. Ariel was right. :) On Fri, Sep 17, 2021 at 4:47 PM Ekaterina Dimitrova <e.dimitr...@gmail.com> wrote: > Gmail cut what I wrote. > > The way I read the excerpt from Benedict’s email below - feature branch > merged on per-phase basis to keep it incremental and easier for > maintenance. Sounds reasonable to me. > > On Fri, 17 Sep 2021 at 16:44, Ekaterina Dimitrova <e.dimitr...@gmail.com> > wrote: > > > 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. > > > > The way I read this - feature split into few phases. Feature branch that > > is merged at the end of a phase. > > Sounds reasonable to me. Incremental work is always preferable, easier to > > maintain. > > > > > > On Fri, 17 Sep 2021 at 16:40, bened...@apache.org <bened...@apache.org> > > wrote: > > > >> 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 > >> > > >
