Hi Benedict, do I need to somehow accommodate this initiative in such a way that I will postpone what I have (like CEP-9 is pretty close to merging) so you have it easier to merge that? It seems to me these patches are quite big and I am just thinking how to make it easier for you - without having to constantly check if something hasn't changed in the meanwhile.
Regards On Tue, 28 Sept 2021 at 14:06, bened...@apache.org <bened...@apache.org> wrote: > > 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 > > >> > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
