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/0ecddfb2ecc72e8c5f4027d96b72345d3476edfe0094f89b42a93539@%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.
