cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Reminder: critical fixes only in 2.1
Date Mon, 18 Jul 2016 17:36:17 GMT
Except there really wasn't.

Patch submitter: "I want this in 2.1."
Reviewer: "Okay."

That's not exactly the bar we're looking for.  To consider a performance
fix "critical" for example, you really need to show at the very least what
new workload you found that isn't able to live with it the way everyone
else did for the previous 15 releases.

I note that on 10433 the committer even said, "I'm not [sure] I agree this
is critical for 2.1 at this point, but as it's simple enough and has been
somewhat vetted on 2.2 by now, not going to argue."

So consider this me putting on my bad cop hat and opening up the argument.

On Mon, Jul 18, 2016 at 12:24 PM, Jeremiah D Jordan <jeremiah@datastax.com>
wrote:

> Looking at those tickets in all three of them the “is this critical to
> fix” question came up in the JIRA discussion and it was decided that they
> were indeed critical enough to commit to 2.1.
>
> > On Jul 18, 2016, at 11:47 AM, Jonathan Ellis <jbellis@gmail.com> wrote:
> >
> > We're at the stage of the release cycle where we should be committing
> > critical fixes only to the 2.1 branch.  Many people depend on 2.1 working
> > reliably and it's not worth the risk of introducing regressions for
> (e.g.)
> > performance improvements.
> >
> > I think some of the patches committed so far for 2.1.16 do not meet this
> > bar and should be reverted.  I include a summary of what people have to
> > live with if we leave them unfixed:
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-11349
> >  Repair suffers false-negative tree mismatches and overstreams data.
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-10433
> >  Reduced performance on inserts (and reads?) (for Thrift clients only?)
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-12030
> >  Reduced performance on reads for workloads with range tombstones
> >
> > Anyone want to make a case that these are more critical than they appear
> > and should not be reverted?
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
>
>


-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message