Just want to weigh in my 2 cents. I've been following the dev list for quite a while and wanted to contribute. As I approached trying to handle some lhf, I couldn't find any instructions on how to check out, build, test or any guidance on coding standards and best practices. Maybe these existed and were hard to find, maybe I was too inexperienced to understand them. Either way, given my experience at the time, I wasn't able to contribute and never came back.
If that hasn't changed, that's where I would start to get more people contributing. I realize the project is pretty complex, but the more we can lower the bar of entry, the more people will contribute. This doesn't help solve the problem of more people to review big changes right away, but perhaps it will free experienced contributors up to help with those. Again, just my 2 cents. On Sat, Nov 5, 2016, 7:19 AM Benedict Elliott Smith <bened...@apache.org> wrote: > 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 > > >
