On 6/17/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote:
If that means things languish for weeks or months, then that's what it means.
I don't think this is a good idea. The RTC process (as Ken is describing it) has a number of side effects: - Eliminates trust. I know say, David J has a lot of experience with say, connectors, and if he puts a patch in that area, I think I can read his summary and trust that he's implemented it sensibly. But now that doesn't count, I have to review it line by line? I think it should be up to me which patches I trust and which patches want to review in detail. - Favors full-time open source developers over free-time contributors. I don't have enough time to work on the work *I* want to do in my spare time, much less get a clean tree to apply, test, and review everyone else's patches - Favors bug fixes over innovation. Anything that's characterized as a bug fix gets a free pass. Also, it's unmanageable to review large changes in detail, so only small changes have any good change of being applied in a timely fashion. - Encourages "cliques". Who am I going to ask to give me a quick +1? Now, you can argue in favor of this for a maintenance / bug-fix release like 1.1.1, where the main goal is to improve quality and extra eyes on every line may help avoid bugs. But it's a significant obstacle for a feature release like 1.2. Additionally, it doesn't help the stated goal of improving communication. If everyone wants to see what I'm doing, and I post it to a Jira and announce it, they can see. If they want to review in detail, they can. If they can review the description and perhaps give it a cursory glance and give it a +1, that's achieved the goal of making sure they're aware of things going on in the project. If you say they can't +1 it without an exhaustive review and test, that doesn't add to the quality or quantity of communication. It only adds obstacles to delivering the features desired for the 1.2 release. Thanks, Aaron
