> On 16 Nov 2015, at 22:50, Greg Stein <gst...@gmail.com> wrote: > > On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon <t...@apache.org> wrote: >> ... > >> 1) You're right, I don't trust anybody to make code changes to a complex >> project with zero oversight. I currently work on a project that I >> > > I have always found the "complex project" to merely be an excuse for > control/no-trust. > > All software is hard. Your project is no more complex than others. > > -g
FWIW some of the projects I'm is CTR; for stuff where it's less complex/critical then yes I enjoy the freedom. I can not only push stuff out fast, I can keep that code hygiene up by doing side things: comments, spelling corrections, other tuning, as I go along. But I do have to track what's going on by others and look at their changes -though now via SCM history within the IDE, rather than .patch files and pull requests. Where I find myself agreeing with todd, however is the bits of the system where getting it wrong could lead to fundamental losses of petabytes worth of data. Which is what you can do if you get something wrong with HDFS or HBase: hence RTC is justifiable. Indeed, get something wrong with the consensus protocols of zookeeper would potentially cause problems for : Hadoop, HBase, cassandra, Mesos, Accumulo & many other things —which is why I'm happy for people other than myself to understand the maths behind it ["Zab: High-performance broadcast for primary-backup systems" | https://web.stanford.edu/class/cs347/reading/zab.pdf ] But at the same time, RTC dissuades me from doing the minor stuff, because the effort to submit a patch to correct a spelling error in a comment is so high. I think it can endanger code quality. There's also the fact that even those bigger patches I may do, will need to be reviewed before commit —and there's a backlog on the Hadoop codebase which includes a lot of mine. Other people are as lax about reviewing those patches as I (sadly) am about reviewing patches from people other than me. It takes effort and time, and if you are working on something full time, where that means evening and weekends as well as daytime, then its easy to neglect things. If someone were to have some metrics of projects, the state of patches/pull requests would be a key issue. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
