"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 <alek...@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 (alek...@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 (zznat...@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 <zznat...@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. >
