cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)
Date Fri, 04 Nov 2016 23:03:15 GMT
"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."

I have to strongly disagree  here. The Cassandra issue tracker is over
12000 tickets. I do not think that cassandra has added 12000 "features"
since it's inception.  I reject this concept that only a hand full of
people are capable of reviewing and merging things. Firstly, if this
process was so insanely bullet proof we never had alternating tick-tock fix
releases. (Unless someone is going to argue we are still fixing zero day
bugs from the facebook code drop :). I in my spare time have passed over
code and found things.

I do not mean this to come off as offensive. There clearly are specialists
and they are well respected. When someone say things like:

"real reviews, not rubber-stamping a +1 formally"

I feel that is really standing up on a soap box. What would be the worst
thing that happens here? A "rubber stamp" review sneaks in and causes bug
12001. OMG! NO SOMEONE RUBBER STAMPED SOMETHING AND CREATED A BUG. THAT
NEVER HAPPENED BEFORE IN THE HISTORY OF THE PROJECT. THERE HAS NEVER BEEN A
UNTESTED FEATURE ADDED WHICH BROKE SOMETHING ELSE. ETC ETC.

Be real about this situation it. Just added sasi stuff has bugs.





On Fri, Nov 4, 2016 at 6:27 PM, Aleksey Yeschenko <aleksey@apache.org>
wrote:

> I’m sure that impactful, important, and/or potentially destabilising
> patches will continue getting reviewed
> by those engineers.
>
> As for patches that no organisation with a strong enough commercial
> interest cares about, they probably won’t.
> Engineering time is quite expensive, most employers are understaffed as it
> is, overloaded with deadlines and
> fires, so it’s hard to justify donating man hours to work that brings no
> value to your employer - be it Instagram,
> Apple, or DataStax.
>
> I don’t want to sound negative here, but I’d rather not fake optimism
> here, either. Expect that kind of patches
> to stay in unreviewed limbo for the most part.
>
> But significant work will still get reviewed and committed, keeping the
> project overall healthy. I wouldn’t worry much.
>
> --
> AY
>
> On 4 November 2016 at 22:13:42, Aleksey Yeschenko (aleksey@apache.org)
> wrote:
>
> 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 work
> 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 contributions.
>
> 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 DataStax
> 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 companies,
> 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.
>
> --
> AY
>
> On 4 November 2016 at 21:50:20, Nate McCall (zznate.m@gmail.com) 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
> involvement.
>
> 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 <zznate.m@gmail.com> 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:
> > https://lists.apache.org/thread.html/0ecddfb2ecc72e8c5f4027d96b7234
> 5d3476edfe0094f89b42a93539@%3Cdev.cassandra.apache.org%3E
> >
> >>
> >> 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.
>

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