On Thu, Nov 12, 2009 at 3:16 AM, Greg Stein <gst...@gmail.com> wrote:
> Not a "strong opinion", but I think that RTC hampers the free-flow of > ideas, experimentation, evolution, and creativity. It is a damper on > expressivity. You maneuver bureaucracy to get a change in. CTR is > about making a change and discussing it. But you get *forward > progress*. I think this entirely depends on how quickly you get an R. I've worked for $BIGCOs that do CTR and have really stifling cultures and $SPUNKYSTARTUPs that do RTC and have huge forward momentum. Momentum which is more sustainable because the explicit review means at least one other person knows what it is that you're doing so there's some instant knowledge sharing to reduce the risk of blind alleys and the bus factor. > I also feel that RTC will tend towards *exclusivity* rather than the > Apache ideal of *inclusivity*. That initial review is a social and > mental burden for new committers. People are afraid enough of > submitting patches and trying to join into a development community, > without making them run through a front-loaded process. I'd flip this around and look at it from the PoV of a not-yet-committer. RTC means everybody goes through basically the same process - (raise jira), hack, submit patch, patch gets reviewed, patch gets committed regardless of whether they have a commit bit or not. CTR means there is a qualitative difference in workflows between committers and non-committers. > I've participated in both styles of development. RTC is *stifling*. I > would never want to see that in any Apache community for its routine > development (branch releases are another matter). I'm sorry you found it that way, I don't think it has to be that way though. :/ > My opinion is that it is very unfortunate that Cassandra feels that it > cannot trust its developers with a CTR model, and pushes RTC as its > methodology. The group-mind smashes down the creativity of the > individual, excited, free-thinking contributor. I think that sort of group mentality is problematic regardless of review model, it's perhaps a bit more commonly found in RTC but I don't think it's inherent to the system (you can insert your own Monty Python reference here if you want). The main benefit I've always found for RTC (beside being slightly flatter, as outlined above), is that it means that the review actually happens and can be seen to have happened. CTR often falls by the wayside, even with tooling. For Qpid 0.5 we used Jira workflow to try and support this and still ended up with something like 50 jiras in "ready to review" state. While it's possible that somebody read the code and couldn't be bothered to click the button, I think it's much more likely that they're basically unreviewed. There's also a number of Jiras that are essentially review comments that have been kicking around for ages. A number of large, venerable projects run with RTC for a number of reasons. I know a lot of people dislike it due to prior bad experience, that it stifles them, holds up progress etc. To them I say http://git-scm.com ;) - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org "A witty saying proves nothing" - Voltaire --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
