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 at 5:59 PM kurt greaves <k...@instaclustr.com> 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 <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 > > > > > -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
