"I’m sure users running Cassandra in production would prefer actual proper reviews to non-review +1s."
Again, you are implying that only you can do a proper job. Lets be specific here: You and I are working on this one: https://issues.apache.org/jira/browse/CASSANDRA-10825 Now, Ariel reported there was no/low code coverage. I went looking a the code and found a problem. If someone were to merge this: I would have more incentive to look for other things, then I might find more bugs and improvements. If this process keeps going, I would naturally get exposed to more of the code. Finally in maybe (I don't know in 10 or 20 years) I could become one of these specialists. Lets peal this situation apart: https://issues.apache.org/jira/browse/CASSANDRA-10825 "If you grep test/src and cassandra-dtest you will find that the string OverloadedException doesn't appear anywhere." Now let me flip this situation around: "I'm sure the users running Cassandra in production would prefer proper coding practice like writing unit and integration test to rubber stamp merges" When the shoe is on the other foot it does not feel so nice. On Fri, Nov 4, 2016 at 7:08 PM, Aleksey Yeschenko <alek...@apache.org> wrote: > Dunno. A sneaky correctness or data corruption bug. A performance > regression. Or something that can take a node/cluster down. > > Of course no process is bullet-proof. The purpose of review is to minimise > the odds of such a thing happening. > > I’m sure users running Cassandra in production would prefer actual proper > reviews to non-review +1s. > > -- > AY > > On 4 November 2016 at 23:03:23, Edward Capriolo (edlinuxg...@gmail.com) > wrote: > > I feel that is really standing up on a soap box. What would be the worst > thing that happens here
