On 8/29/07, Bob Scheifler <[EMAIL PROTECTED]> wrote: > I dislike code review deadlines; code isn't correct just because a deadline > passes. I also don't ever expect committers to be expert in the entire > codebase, so I'm wary of accepting +1's from only those who don't really > understand the code being changed. So for implementation changes I'm tempted > towards having a set of gatekeepers for each component (achieved by merit), > and review must have a +1 from a gatekeeper, and no vetoes within > max(N days, vote by gatekeeper).
I think this email, other than convincing me even more that RTC is bad in general and wrong in this context, is a clear sign that we need to step back a minute and try to understand what we are really after. First of all, what are we trying to achieve? What is our top priority? As an ASF incubating project, the ultimate goal should be proving how River is sustainable from a community perspective, much rather than demonstrating technical excellence. While I can understand that River is currently used in production in a number of places, with lots of users relying on its quality and robustness, I still contend that the main objective of this timeframe should be getting others involved. And it would be damn hard achieving that if there are too many gates to cross. If the codebase is too complex, the solution isn't raising artificial barriers to avoid others from making silly mistakes. The solution making it easier to grasp and provide a good community framework that clearly outlines roles and responsibilities *while* promoting participation. For one, I see the notion of "supercommitter" (or gatekeeper, in Bob words) as extremely harmful. In ASF-land there is no such thing (and this is a problem in itself). We do have people responsiblle for parts of the code, but this is usually governed by trust and common sense: people won't commit crap to the repo just because they can, they will resort to whomever knows best. I am, formally, a River committer, yet I'm (very!) far from changing a single line of code. Heck, I did check out the repo just to make sure that there were no obvious legal issues. And I'm not going to vote on technical issues, no matter what: all you will be seeing from me are abstains or, at most, +-0s. I know where I stand, I know what my role is, I know if and when I can talk about the codebase (never, for the time being) or vote about legal/community issues (always). Side note: I grew up as a commiter in Cocoon-land which, as some of you may know, is a highly complex beast, very modular and with a lot of different technologies involved. When I was an active developer, I was following a few modules, where I felt confident and knowledgeable enough to directly commit code. Of course from time to time I had to chime in someone else's realm, where I possibly knew the big picture but I was definitely a complete ignorant about the actual implementation and potential impact of my changes. In such cases, I resorted to posting to the mailing list, possibly with a proposal/diff, and wait for a green light from the "gatekeeper", that is someone I knew was knowledgeable enough. Think of it as an informal, community-oriented, RTC in a CTR environment. And believe me, it just works: when meritocracy is at work, committers aren't just people with technical skills, they know how to work within a community. I think River needs to recreate such an environment. And this is why I see a lot of slippery slopes in introducing control-based processes that don't take reciprocal trust into account. This is not to say that RTC is bad in itself: it might work as an excellent tool to ensure control where control is key (stuff like backports, security issues, et al), just make sure it's there for the correct reasons. Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
