cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedict Elliott Smith <bened...@apache.org>
Subject Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)
Date Sat, 05 Nov 2016 13:19:11 GMT
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
>

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