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 <adwei...@fastmail.fm> wrote: > 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 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. > > Regards, > Ariel > > > On Nov 18, 2018, at 9:18 PM, Vinay Chella <vinaykumar...@gmail.com> > wrote: > > > > 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 > we > > 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 > that > > 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 > read/write > > calls on C*. This patch allows users to detect when they are choosing > > incorrect coordinators. (Usability bug (troubleshoot), Review in > progress) > > > > 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, > Production > > 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 > nice > > 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 > hints > > that are accumulated over a period of time when nodes are creating are > less > > likely to take down the entire cluster. (Potential Production Impact, > Patch > > Available) > > > > CASSANDRA-14291: Bug from CASSANDRA-11163? (Usability Bug, Patch > Available) > > > > CASSANDRA-10540: RangeAware compaction. 256 vnode clusters really need > this > > 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 > > < > https://issues.apache.org/jira/issues/?filter=12345151&jql=project%20%3D%20CASSANDRA%20AND%20key%20in%20(CASSANDRA-14525%2C%20CASSANDRA-13010%2C%20CASSANDRA-10023%2C%20CASSANDRA-10789%2C%20CASSANDRA-13841%2C%20CASSANDRA-14309%2C%20CASSANDRA-12783%2C%20CASSANDRA-14291%2C%20CASSANDRA-10540%2C%20CASSANDRA-14303%2C%20CASSANDRA-14557%2C%20CASSANDRA-14459%2C%20CASSANDRA-9452%2C%20CASSANDRA-14096%2C%20CASSANDRA-14319)%20ORDER%20BY%20assignee%20ASC%2C%20reporter%20ASC > > > > > > > > Let me know. > > Thanks, > > Vinay Chella > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
