Another note about 14557 - this also lets us fix 3.0 regression where we
cannot bootstrap new nodes until system_auth keyspace (that comes up with
RF=1) is "altered" to a higher RF. Instead, with 14557, one can set yaml
property minimum_keyspace_rf to, say, 3 and system keyspaces would honor it
With 14303 in (thanks to Jon), wanted to see if I can get help on 14557 -
it makes it further easy to create keyspaces (without having to always
mention RF) and provides a way to ensure keyspaces are created with a
minimum required RF.
Thanks,
Sumanth
On Wed, Dec 5, 2018 at 5:35 PM Vinay Chella
Thanks for the responses, I think the summary so far is: committers and
reviewers are positive on reviewing the community tickets mentioned in this
email except for a couple of them that Joshua mentioned, with the caution of
not disrupting the current testing efforts.
Thank you, Ariel, for
We already should be taking correctness and perf changes and I am +1 on taking
operational tickets. Agree with Josh that the only exception will be if it
causes disruption in testing.
I think as a project we should be more open to operational issues as having a
fork is not ideal.
Regarding
Strong +1 on prioritizing community engagement 1st and caution second,
though still prioritizing it. I think the right metric for us to calibrate
around is that "disrupt in-flight testing cycles", i.e. if changes cause
significant rework for people that have already begun testing 4.0, probably
ok
> I assume it's obvious to everyone that this should be taken on a
> case-by-case basis. There's at least 2 that were in that list (one of which
> Marcus bumped off PA) that are potentially big and hairy changes that would
> disrupt in-flight testing cycles.
Agreed. I’d prefer we aim to be as
> If those tickets were sitting in patch available state prior to the
freeze they *should* get in.
I assume it's obvious to everyone that this should be taken on a
case-by-case basis. There's at least 2 that were in that list (one of which
Marcus bumped off PA) that are potentially big and hairy
Kurt, I don't believe this should be subject of "heated debate". If those
tickets were sitting in patch available state prior to the freeze they *should*
get in.
Vinay, I can help review the tickets.
Dinesh
On Tuesday, November 20, 2018, 2:59:18 PM PST, kurt greaves
wrote:
Thanks
If nobody has any objections to CASSANDRA-14303 (default RF) being merged
in I can take care of it. It's a significant usability improvement, looks
well tested and will prevent a number of headaches.
I'll try to get to it tomorrow.
Thanks for bringing these up, Vinay.
Jon
On Tue, Nov 20, 2018
Thanks Vinay. While I suspect this will be subject to heated debate, I'm
also for this. The time to review for this project is incredibly
demotivating, and it stems from a lack of contributors that are interested
in the general health of the project. I think this can be quite easily
remedied by
Hi,
I would like to get as many of these as is feasible in. Before the feature
freeze started 1 out of 17 JIRAs that were patch available were reviewed and
committed.
If you didn’t have access reviewers and committers, as the one out of the 17
did, it has been essentially impossible to get
Hi,
We still have 15 Patch Available/ open tickets which were requested for
reviews before the Sep 1, 2018 freeze. I am starting this email thread to
resurface and request a review of community tickets as most of these
tickets address vital correctness, performance, and usability bugs that
help
12 matches
Mail list logo
