cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksey Yeschenko <>
Subject Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)
Date Fri, 04 Nov 2016 22:13:42 GMT
This has always been a concern. We’ve always had a backlog on unreviewed patches.

Reviews (real reviews, not rubber-stamping a +1 formally) are real work, often taking as much
as creating the patch in question. And taking as much expertise (or more).

It’s also not ‘fun’ and doesn’t lend itself to scratch-your-own-itch drive-by style

In other words, not something people tend to volunteer for. Something done mostly by people
paid to do the work, reviews assigned to them by their managers.

There is also the issue of specialisation. Very few people can be trusted with review of arbitrary
Cassandra patches. I can count them all on fingers of one hand. There are islands of expertise
and people who can review certain subsystems, and most of them are employed by a certain one
company. A few people at Apple, but with no real post-8099, 3.0 code experience at the moment.

What I’m saying is that it’s insufficient to just have desire to volunteer - you also
need the actual
knowledge and skill to properly review non-trivial work, and for that we largely only have
employed contributors, with a sprinkle of people at Apple, and that’s sadly about it.

We tried to improve it by holding multiple bootcamps, at Summits, and privately within major
at non-trivial expense to the company, but those initiatives mostly failed so far :(

This has always been a problem (lack of review bandwidth), and always will be. That said,
I don’t expect it to get
much worse than it is now.


On 4 November 2016 at 21:50:20, Nate McCall ( wrote:

To be clear, getting the community more involved is a super hard,  
critically important problem to which I don't have a concrete answer  
other than I'm going to keep reaching out for opinions, ideas and  

Just like this.  

Please speak up here if you have ideas on how this could work.  

On Sat, Nov 5, 2016 at 10:38 AM, Nate McCall <> wrote:  
> [Moved to a new thread because this topic is important by itself]  
> There are some excellent points here - thanks for bringing this up.  
>> What can inspiring developers contribute to 4.0  
>> that would move the project forward to it’s goals and would be very likely  
>> included in the final release?  
> That is a hard question with regards to the tickets I listed. My goal  
> was to list the large, potentially breaking changes which would  
> necessitate a move from '3' to '4' major release. Unfortunately in  
> this context, those types of issues have a huge surface area that  
> requires experience with the code to review in a meaningful way.  
> We are kind of in this trap now with the Gossip 2.0 tickets. There are  
> very few people who feel comfortable enough to give Jason feedback on  
> the patches because he has effectively replaced (necessarily, IMO)  
> seven years of edge case fixes baked into the current implementation.  
> And that stuff is just hard in the first place.  
> I'm not completely sure what the answer is here. I will tell you that  
> from my own experience, an excellent way to get familiar with the code  
> and concepts would be to look at some of these large tickets in  
> detail, go through what changed and ask some questions about the  
> choices made.  
> Community is based on participation, conversation and exchange of  
> knowledge. The more involvement we have in day to day exchanges, the  
> more we all learn and the healthier things will become.  
>> What should people work on that would not be  
>> left ignored, because there’s no need for it or no time to really take care  
>> of it?  
> We have a huge pile of backlogged tickets in "unresolved" and "patch  
> available." Going through these and testing, reviewing, submitting  
> patches, even pinging on status, rebasing if needed would be awesome.  
> Frankly, we need the help.  
> Another thought - "I would like to add X, how should I go about doing  
> this?" is an excellent conversation to start on the mail list:  
>> Each contribution  
>> deserves some kind of response and even if it’s just a “not relevant for  
>> next release, will look into it another time” type of reply.  
> I completely agree. Per the above, anyone should feel like they can  
> chime in on tickets. It's a community effort.  
> Particularly if you are an operator - your thoughts, experiences and  
> opinions matter (to me at least) like 10x what a developer thinks for  
> anything with operational or end user impact.  
>> Having clear  
>> goals or a certain theme for the release should make it easier to decide  
>> what to review and where to decline. Does that make sense?  
> I think anything *new* with a large surface area not already well  
> underway (and maybe some things that are?) should be tabled for 5 at  
> this point. We really need to focus on stability via community  
> involvement.  

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