On Sat, Nov 23, 2002 at 04:43:27PM -0800, Aaron Bannert wrote: > On Saturday, November 23, 2002, at 03:33 PM, Henning Brauer wrote: > > On Sat, Nov 23, 2002 at 02:19:35PM -0800, Aaron Bannert wrote: > >> What will R-T-C give us that we don't already have right now? > > > > code quality... > > > > really, this isn't meant as flame. There's enough room for code quality > > increase, and with C-T-R you will not get it. > > > > the analogy for our stable maintainers is most probably your RM. > > so after you've done a release in the 2.0 branch, you select a RM for > > the > > next release, who then is 2.0 branch maintainer until next release. > > I simply do not believe that code quality in httpd will be improved > by a R-T-C policy, and I have seen nothing to disprove this belief. > > To the contrary, I believe that by placing more speedbumps on the > path between patch and commit, we have a possibility to reduce > quality. In C-T-R a patch can be tested simply by running a "cvs up", > recompiling, and rerunning. In the proposed R-T-C, a committer > must first acquire the patch and apply it before they can even start > testing. > > We have a revision control system, use it!
Right. RTC is just a mechanism to slow down the things that are right. As Aaron pointed out, we *are* adults. We know what should be committed to the stable branch, and what shouldn't. We know what should only go onto the dev branch. We do that today w.r.t Apache 2.0 and Apache 1.3. The problem is that there isn't an outlet for rapid advance of the 2.x series, so 2.0 gets the churn even while we're trying to be stable. Apache 1.3 is nice and stable because people can "play" elsewhere. We need to play somewhere besides the 2.0 stable branch. Call 2.0 stable and create a 2.1 dev area. The developers will take the changes to the right location. Trust them to do that. Don't impose rules -- those do nothing put piss off a properly functioning dev community. Cheers, -g -- Greg Stein, http://www.lyra.org/
