>>>> [EMAIL PROTECTED] Tuesday, November 16, 2004 4:29:31 PM >>> > * "Brad Nicholes" <[EMAIL PROTECTED]> wrote:
>> During ApacheCon several httpd PMC members got together to discuss >> current issues with the httpd project and to try to find better ways to >> manage the project. One of the issues that was discussed heavily was >> the current policy of RTC vs CTR. The feeling of some of the PMC >> members is that the RTC policy as it is currently implemented on the 2.0 >> branch, is causing unnecessary overhead which has resulted in the >> slowdown of activity in the httpd project. One proposal that was made >> would be to adopt a lazy consensus rule. Basically what this means is >> that when a backport is proposed in the STATUS file, after a period of >> time and if the proposal has not recieved any 0 or -1 votes, it would >> automatically be approved for backport by lazy consensus. The purpose >> for this proposal is to avoid stagnation of backport proposals in the >> STATUS file simply due to the lack of votes. -1 (vote not veto) Stability is much more important than backport of some features. Backporting code into the stable branch without any review will increase the risk of new bugs. What I see, is not stagnation. Instead, I do see more effort because of our backport policy. Development is done for two versions. This binds time and power. > IMHO a better way bring the development further is the suggestion on the dev > list. *absolute* feature freeze on stable branches (except 1.3?), bug fixes > only. Though it would need some time to establish the trust of the community > in so much more versions, I like that idea somehow. +1 Additionally, let's do 2.1 tarballs to bring the current development branch to a wider group of devs and testers. Kess
