cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Luciani <jak...@gmail.com>
Subject Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)
Date Sat, 05 Nov 2016 15:21:07 GMT
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 <thattolleyguy@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 <benedict@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 <edlinuxguru@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 <aleksey@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 (
> edlinuxguru@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message