At 01:45 PM 11/14/2003, Sander Striker wrote: >On Thu, 2003-11-13 at 09:06, Jeff Trawick wrote: >> Aaron Bannert wrote: >> >> > On Tue, Nov 11, 2003 at 09:55:24AM -0700, Brad Nicholes wrote: >> >> Just to point out the obvious fact that hopefully everybody can agree with and >> consider taking action on: More code review[er]s would be useful regardless of >> C-T-R vs. R-T-C. And whether or not you agree with the current order of >> Committing and Reviewing for the stable branch, helping out with reviews would >> result in fixes being merged into the stable branch much faster. > >Exactly. And may I also note that releases are way more likely not to >be duds now we are using R-T-C on the stable branch? I have noticed a >significant difference in effort it takes to release since we switched >stable to R-T-C.
++1. When something must-be-fixed (such as building on the fd/handle inheritence fixes that were introduced for security, but introduced a few new bugs --- or the cgid issues) - a new release on 2.0 can be created with little hassle and is doesn't require each platform guru to 'weigh in' on new breakage on their platform. Nobody minds breakage in the process of improving the project. When httpd 2.0 and 2.1 were broken apart, we provided an autobaun for new development (2.1) that is as unstable as necessary to move forward, and maintained a nice, solid two lane bypass (2.0) that was reliable and ready to tag as a release with little pain and maximum return. Some may suggest this has slowed down development. I'd ask, do you have a patch that you didn't commit to 2.1 yet? If so, why not? I'd ask, if you are arguing about 2.0 - what's not moving forward 'fast enough' for your taste? Your patch is stuck, awaiting review? This last question I ask then is - if you are waiting for others to review your patch, how many patches did you provide review and feedback for last week? This must be a collaborative effort, if you aren't reviewing patches - please don't moan when there are too few folks to review your own patch. Bill