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