Hi Ed, I would like to try and clear up what I perceive to be some misunderstandings.
Aleksey is relating that for *complex* tickets there are desperately few people with the expertise necessary to review them. In some cases it can amount to several weeks' work, possibly requiring multiple people, which is a huge investment. EPaxos is an example where its complexity likely needs multiple highly qualified reviewers. Simpler tickets on the other hand languish due to poor incentives - they aren't sexy for volunteers, and aren't important for the corporately sponsored contributors, who also have finite resources. Nobody *wants* to do them. This does contribute to an emergent lack of diversity in the pool of contributors, but it doesn't discount Aleksey's point. We need to find a way forward that handles both of these concerns. Sponsored contributors have invested time into efforts to expand the committer pool before, though they have universally failed. Efforts like the "low hanging fruit squad" seem like a good idea that might payoff, with the only risk being the cloud hanging over the project right now. I think constructive engagement with potential sponsors is probably the way forward. (As an aside, the policy on test coverage was historically very poor indeed, but is I believe much stronger today - try not to judge current behaviours on those of the past) On 5 November 2016 at 00:05, Edward Capriolo <edlinuxg...@gmail.com> wrote: > "I’m sure users running Cassandra in production would prefer actual proper > reviews to non-review +1s." > > Again, you are implying that only you can do a proper job. > > Lets be specific here: You and I are working on this one: > > https://issues.apache.org/jira/browse/CASSANDRA-10825 > > Now, Ariel reported there was no/low code coverage. I went looking a the > code and found a problem. > > If someone were to merge this: I would have more incentive to look for > other things, then I might find more bugs and improvements. If this process > keeps going, I would naturally get exposed to more of the code. Finally in > maybe (I don't know in 10 or 20 years) I could become one of these > specialists. > > Lets peal this situation apart: > > https://issues.apache.org/jira/browse/CASSANDRA-10825 > > "If you grep test/src and cassandra-dtest you will find that the string > OverloadedException doesn't appear anywhere." > > Now let me flip this situation around: > > "I'm sure the users running Cassandra in production would prefer proper > coding practice like writing unit and integration test to rubber stamp > merges" > > When the shoe is on the other foot it does not feel so nice. > > > > > > > > > > > On Fri, Nov 4, 2016 at 7:08 PM, Aleksey Yeschenko <alek...@apache.org> > wrote: > > > Dunno. A sneaky correctness or data corruption bug. A performance > > regression. Or something that can take a node/cluster down. > > > > Of course no process is bullet-proof. The purpose of review is to > minimise > > the odds of such a thing happening. > > > > I’m sure users running Cassandra in production would prefer actual proper > > reviews to non-review +1s. > > > > -- > > AY > > > > On 4 November 2016 at 23:03:23, Edward Capriolo (edlinuxg...@gmail.com) > > wrote: > > > > I feel that is really standing up on a soap box. What would be the worst > > thing that happens here >
