Hi Tyler, There is a nice guide now in the docs on how to contribute[1]. If you try it and find holes you can also help by contributing to those docs.
-Jake [1]: http://cassandra.apache.org/doc/latest/development/index.html On Sat, Nov 5, 2016 at 11:08 AM, Tyler Tolley <thattolley...@gmail.com> wrote: > 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 > > > > > > -- http://twitter.com/tjake
