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
