-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Mulder wrote: > 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.
RTC means tested quality, not assumed quality. If you can't find people to test the quality of something, it doesn't go in because the quality isn't assured. > - 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. Considering the problems concerning trust that are already extant, I think the first sentence as a conclusion is bogus. And once again you want to *assume* quality rather than *assure* it. That's how CTR works. RTC works to *assure* it. > - 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 I don't consider this valid, either. If you have the time to be a committer, you have the time to be part of the community and collaborate with your peers on the project. One thing about RTC is that it tends to promote interaction, since people are dependent on each other and the occasional quid pro quo -- unlike the everyone haring off in his own direction with no-one else watching that can occur (and has occurred) under CTR. No-one says you have to test *anyone* else's patches. Unless, of course, you hope they'll test *yours*, which is where the collaboration-for-the-project aspect comes in. So if you don't find time to test someone else's code, regardless of for whom he may work, don't expect him to spend a lot of time testing *yours*. > - Favors bug fixes over innovation. Anything that's characterized as > a bug fix gets a free pass. Quality, remember? Not bells or features. > 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. Time, time, time. What is this obsession with getting a perfect release out according to some arbitrary schedule? > - Encourages "cliques". Who am I going to ask to give me a quick +1? Rubbish. 'Cliques' is exactly what the previous environment supported. No such thing as a 'quick +1,' unless the patch has been tested quickly -- and by three people. Anyone who gives a quick +1 as lip-service under RTC is in trouble. > 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. Only if some specific date schedule is a factor. And if it is, I ask again: why? Or if the 'features' aren't sufficiently popular among the developers -- in which case why should they be included? > Additionally, it doesn't > help the stated goal of improving communication. I disagree here, as well. I think it has already done a tremendous job 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. You're replacing the 'must be reviewed' aspect of RTC -- which is the major point -- with 'reviewed if people feel like it and remember to.' RTC means that you can't unilaterally and arbitrarily do things *without* discussion. Like, say, setting up a non-project-sponsored .com site and pointing project code at it without discussion. > 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. I regard the first sentence as as a completely baseless assertion. For the second.. Again, only if time is a factor. Or if changes are too uninteresting to be able to get three people to even look at them. - -- #ken P-|} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRJQ1JZrNPMCpn3XdAQKLAQQAx58qgOEEdnrL79vPuXn8AWYwgrVcwH1j X7cnZsvTGmQ4uZW7GiCjjkU2E0H0gGMIRUHFCuV8lul85DectAxE3+4M6pYPAG8v wzg8OOYUl4Wmv6s31M1VDBruCseGLh01c+ilYl2G61mM+c+Ppt3dduD/VCqQDeao 38KzZSDD1WM= =M+w0 -----END PGP SIGNATURE-----
