Thanks for the responses, I think the summary so far is: committers and reviewers are positive on reviewing the community tickets mentioned in this email except for a couple of them that Joshua mentioned, with the caution of not disrupting the current testing efforts.
Thank you, Ariel, for understanding the concerns and helping with reviews. Thank you, Jon, for picking up CASSANDRA-14303. @Joshua, if you can comment on the tickets that concern you that would be helpful, and I will take them off from my list to track for 4.0. I would like to help drive these tickets to their completion in 4.0 (either deferred or committed) unless someone has concerns. Thanks, Vinay On Thu, Nov 22, 2018 at 6:19 PM Sankalp Kohli <kohlisank...@gmail.com> wrote: > We already should be taking correctness and perf changes and I am +1 on > taking operational tickets. Agree with Josh that the only exception will be > if it causes disruption in testing. > > I think as a project we should be more open to operational issues as > having a fork is not ideal. > > Regarding time it is taking to review things, I think we should not start > doing big features post 4.0 but instead review all possible JIRAs first. > Once we are out of this debt, we should define a process so that we don’t > end up in this state. I think this item deserves a separate thread which we > can start closer to 4.0 being cut. > > > On Nov 23, 2018, at 12:17 AM, Joshua McKenzie <jmcken...@apache.org> > wrote: > > > > Strong +1 on prioritizing community engagement 1st and caution second, > > though still prioritizing it. I think the right metric for us to > calibrate > > around is that "disrupt in-flight testing cycles", i.e. if changes cause > > significant rework for people that have already begun testing 4.0, > probably > > ok to review and get it in but target 4.0.x. > > > > On Thu, Nov 22, 2018 at 12:00 PM Benedict Elliott Smith < > bened...@apache.org> > > wrote: > > > >>> I assume it's obvious to everyone that this should be taken on a > >>> case-by-case basis. There's at least 2 that were in that list (one of > >> which > >>> Marcus bumped off PA) that are potentially big and hairy changes that > >> would > >>> disrupt in-flight testing cycles. > >> > >> Agreed. I’d prefer we aim to be as permissive as practical, though. > >> > >> > >> --------------------------------------------------------------------- > >> 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 > >
