Re: Request to review feature-freeze proposed tickets
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.
On Tuesday, November 20, 2018, 2:59:18 PM PST, kurt greaves <kurt@xxxxxxxxxxxxxxx> wrote:
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 making more committers/PMC, however there is a catch-22 that to
achieve this our existing set of committers needs to be dedicated to
reviewing contributions from non-committers.
If we can get dedicated reviewers for the listed tickets I'll take on some
of the work to get the tickets up to scratch.
On Wed, 21 Nov 2018 at 02:12, Ariel Weisberg <adweisbe@xxxxxxxxxxx> wrote:
> 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 your problems with
> Cassandra fixed in 4.0.
> This is basically the same as saying that despite the fact Cassandra is
> open source it does you no good because it will be years before the issues
> impacting you get fixed even if you contribute the fixes yourself.
> Pulling up the ladder after getting “your own” fixes in is a sure fire way
> to fracture the community into a collection of private forks containing the
> fixes people can’t live without, and pushing people to look at alternatives.
> Private forks are a serious threat to the project. The people on them are
> at risk of getting left behind and Cassandra stagnates for them and becomes
> uncompetitive. Those with the resources to maintain a seriously diverged
> fork are also the ones better positioned to be active contributors.
> > On Nov 18, 2018, at 9:18 PM, Vinay Chella <vinaykumarcse@xxxxxxxxx>
> > 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 avoid critical production issues. I tried to provide context on why
> > feel these tickets are important to get into 4.0. If you would like to
> > discuss the technical details of a particular ticket, let's try to do
> > in JIRA.
> > CASSANDRA-14525: Cluster enters an inconsistent state after bootstrap
> > failures. (Correctness bug, Production impact, Ready to Commit)
> > CASSANDRA-14459: DES sends requests to the wrong nodes routinely. (SLA
> > breaking latencies, Production impact, Review in progress)
> > CASSANDRA-14303 and CASSANDRA-14557: Currently production 3.0+ clusters
> > cannot be rebuilt after node failure due to 3.0’s introduction of the
> > system_auth keyspace with rf of 1. These tickets both fix the regression
> > introduced in 3.0 by letting operators configure rf=3 and prevent future
> > outages (Usability bug, Production impact, Patch Available).
> > CASSANDRA-14096: Cassandra 3.11.1 Repair Causes Out of Memory. We believe
> > this may also impact 3.0 (Title says it all, Production impact, Patch
> > Available)
> > CASSANDRA-10023: It is impossible to accurately determine local
> > calls on C*. This patch allows users to detect when they are choosing
> > incorrect coordinators. (Usability bug (troubleshoot), Review in
> > CASSANDRA-10789: There is no way to safely stop bad clients bringing down
> > C* nodes. This patch would give operators a very important tool to use
> > during production incidents to mitigate impact. (Usability bug,
> > Impact (recovery), Patch Available)
> > CASSANDRA-13010: No visibility into which disk is being compacted to.
> > (Usability bug, Production Impact (troubleshoot), Review in progress)
> > CASSANDRA-12783 - Break up large MV mutations to prevent OOMs (Title says
> > it all, Production Impact, Patch InProgress/ Awaiting Feedback)
> > CASSANDRA-14319 - nodetool rebuild from DC lets you pass invalid
> > datacenters (Usability bug, Production impact, Patch available)
> > CASSANDRA-13841 - Smarter nodetool rebuild. Kind of a bug but would be
> > to get it in 4.0. (Production Impact (recovery), Patch Available)
> > CASSANDRA-9452: Cleanup of old configuration, confusing to new C*
> > operators. (Cleanup, Patch Available)
> > CASSANDRA-14309: Hint window persistence across the record. This way
> > that are accumulated over a period of time when nodes are creating are
> > likely to take down the entire cluster. (Potential Production Impact,
> > Available)
> > CASSANDRA-14291: Bug from CASSANDRA-11163? (Usability Bug, Patch
> > CASSANDRA-10540: RangeAware compaction. 256 vnode clusters really need
> > to be able to do basic things like repair. The patch needs some rework
> > after transient replication (Production impact, needs contributor time)
> > URL for all the tickets: JIRA
> > <
> > Let me know.
> > Thanks,
> > Vinay Chella
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx