My PoV re: perf: if it's a regression or something that makes a new feature just Not Work, mark it as bug.
All else mark improvement and can go in in patch rel. On Tue, Mar 31, 2020 at 9:17 PM Jake Luciani <jak...@gmail.com> wrote: > > I see what you mean, I guess my personal line is: does this work worse than > the previous released version? > Seems like that's a yes in this case :) > > On Tue, Mar 31, 2020 at 7:35 PM David Capwell <dcapw...@gmail.com> wrote: > > > One ticket I wanted to bring up is CASSANDRA-15566, this ticket is not a > > regression but it is a critical bug. Personally I feel that only > > regression should go into a freeze so I have a hard time justifying that > > ticket right now (all known failure modes have been failing since at least > > 2.1). I guess the thing that is hard is where do we draw the line? One > > person's bug is another person's improvement, so it's easy for different > > perspectives to clash on this. > > > > > > On Tue, Mar 31, 2020, 3:27 PM Joseph Lynch <joe.e.ly...@gmail.com> wrote: > > > > > On Tue, Mar 31, 2020 at 1:27 PM Jake Luciani <jak...@gmail.com> wrote: > > > > > > > > Can we agree to move the improvements out to 4.0.x? > > > > > > Generally I've been asked to put performance issues as improvements, > > > e.g. CASSANDRA-15379. To be frank though we can't run ZstdCompressor > > > on real clusters without that patch, and therefore I wouldn't feel > > > great releasing ZstdCompressor in 4.0 without that patch. > > > > > > I'm fine to start calling all performance issues "bugs" since at least > > > in our deployments and I think in many others performance regressions > > > are P0 bugs that cost a lot of $$, or we can just keep calling them > > > improvements and just tag them with the ~right target fix version. > > > Namely 4.0-alpha if the change impacts any public interface in a non > > > backwards compatible way (yaml, properties, cql, jmx etc...), 4.0-beta > > > or later if it does not require changes to public interfaces. > > > > > > -Joey > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > -- > http://twitter.com/tjake --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
