Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
MIME-Version: 1.0
In-Reply-To: <etPan.581d0b44.74df821f.2b4@apache.org>
References: <CABsaHTN3owQb_K_nknm2Feb65aUyQEnc5BRR+u0qkBVfKR4Nig@mail.gmail.com>
 <CABsaHTM4rRQgHFU1JVgJhqvr6953BBgVVfe4T39NBjh86LUq_A@mail.gmail.com>
 <etPan.581d0816.7b49e1d4.2b4@apache.org> <etPan.581d0b44.74df821f.2b4@apache.org>
From: Edward Capriolo <edlinuxguru@gmail.com>
Date: Fri, 4 Nov 2016 19:03:15 -0400
Message-ID: <CAENxBwyeg6Bi9bYUUP7GMduaR62T5=manCboExtypx=k1qu8rw@mail.gmail.com>
Subject: Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)
To: "dev@cassandra.apache.org" <dev@cassandra.apache.org>
Content-Type: multipart/alternative; boundary=001a11411c6aec4f4f054081ad55
archived-at: Fri, 04 Nov 2016 23:03:24 -0000

--001a11411c6aec4f4f054081ad55
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

"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=E2=80=99m sure that impactful, important, and/or potentially destabilis=
ing
> 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=E2=80=99t.
> Engineering time is quite expensive, most employers are understaffed as i=
t
> is, overloaded with deadlines and
> fires, so it=E2=80=99s hard to justify donating man hours to work that br=
ings no
> value to your employer - be it Instagram,
> Apple, or DataStax.
>
> I don=E2=80=99t want to sound negative here, but I=E2=80=99d rather not f=
ake 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=E2=80=99t worry much.
>
> --
> AY
>
> On 4 November 2016 at 22:13:42, Aleksey Yeschenko (aleksey@apache.org)
> wrote:
>
> This has always been a concern. We=E2=80=99ve always had a backlog on unr=
eviewed
> 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=E2=80=99s also not =E2=80=98fun=E2=80=99 and doesn=E2=80=99t lend itse=
lf to scratch-your-own-itch
> drive-by style contributions.
>
> In other words, not something people tend to volunteer for. Something don=
e
> 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=E2=80=99m saying is that it=E2=80=99s insufficient to just have de=
sire 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=E2=80=
=99s
> 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 faile=
d
> so far :(
>
> This has always been a problem (lack of review bandwidth), and always wil=
l
> be. That said, I don=E2=80=99t 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=E2=80=99s 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=E2=80=99s no need for it or no time to rea=
lly 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=E2=80=99s just a =E2=80=
=9Cnot relevant for
> >> next release, will look into it another time=E2=80=9D 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 deci=
de
> >> 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.
>

--001a11411c6aec4f4f054081ad55--