If the performance issue is a regression compared to 3.11 that makes total sense. And in the case of ZStd since that's new if its unusable without the "improvement" then it also makes sense.
I think in both cases though it makes sense to classify these as performance regression bugs. I'll take a deeper look at the Improvement tickets, perhaps they all fall into this category. Jake On Tue, Mar 31, 2020 at 6: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