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
