D'oh, too late to respond :)
I was going to comment that leaving the non-critical commits in 2.1 is
probably OK at this point (the deed has already been done), as long as we
agree to become more rigorous in the future about critical bugs vs bugs vs
minor enhancements vs major features and in which
Sounds like we have consensus on that. I will handle the reverts and
update Jira.
On Wed, Jul 20, 2016 at 7:11 PM, Aleksey Yeschenko
wrote:
> Keep #11349, revert the rest sounds reasonable.
>
> --
> AY
>
> On 20 July 2016 at 22:27:05, sankalp kohli (kohlisank...@gmail.com) wrote:
>
> +1 on only
Keep #11349, revert the rest sounds reasonable.
--
AY
On 20 July 2016 at 22:27:05, sankalp kohli (kohlisank...@gmail.com) wrote:
+1 on only allowing critical bug fixes.
I agree with Sylvain that CASSANDRA-11349 is a border line critical bug. I
would vote for CASSANDRA-11349 as being critica
+1 on only allowing critical bug fixes.
I agree with Sylvain that CASSANDRA-11349 is a border line critical bug. I
would vote for CASSANDRA-11349 as being critical since over streaming is a
big issue for us as well. I am also fine taking it as an internal patch
since we already maintain an interna
Hi,
I'm the reporter for CASSANDRA-11349.
Just a bit of history:
This was a big pain point for us because the over-streaming was really
important.
Each week, repair increased data size by a few percents.
To give an example, one cluster with 12 nodes had a CF with around 250GB of
data per node and
Definitively agrees that CASSANDRA-10433 and CASSANDRA-12030 aren't
critical. In fact, they are both marked as "improvements" and "minor". I'm
to blame for their commit, so mea culpa. But to my defense, I've long
advocated for being stricter on sticking to critical-only fixes on old
releases and ha
+1 from me (and I don’t see any resistance to it either).
--
AY
On 18 July 2016 at 18:36:42, Jonathan Ellis (jbel...@gmail.com) wrote:
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 perform
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 e
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 wrote:
>
> We're at the stage of the release cycle where
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.
10 matches
Mail list logo