Taking a snapshot look at the STATUS file at any given point in time does not show the actual problem. The problem is the delay in getting from point A (submitting a proposal) to point B (approval for backport). For a hot issue with many interested parties (who actually hold voting rights), getting a backport proposed and accepted is rather quick. In such cases I would even suggest that the backport proposal policy is simply a formality and overhead because those voting on a hot issue have already reviewed the issue even before it hit the STATUS file. So rather than just checking in a patch that has already been reviewed by the dev@ list, it is delayed simply on formality. But that is a different discussion on a minor point.
The main evidence is the trend that is happening before each release. A release is proposed, an RM is selected, the RM sets a deadline and everybody emails the list with their favorite backport issue. Now the RM has to deal not only with the release but whether or not a backport has been accepted, can the tree be tagged yet, does a tag need to be moved, etc. Oh Oops a backport didn't make it and now we need to issue a release patch for a segfault(http://www.apache.org/dist/httpd/patches/apply_to_2.0.52/). Not only that but IMO, this in itself is a major contributor to destabilization. The best way to make sure that the branch is stable is to get it out in front of those that are testing and using it. Not throw a bunch of patches in right before we release just because they got three +1's. Implementing lazy consensus would make others aware of proposed backports, allow them to review the issue if interested and allow the backport to move smoothly and quickly through the process without having to beg the list for reviewers at the last minute. The opposite question is what evidence do we have that RTC isn't doing more harm than good once the branch is stable? And please don't point to the mess that happened between 2.0.35 and 2.0.4x. IMO, that mess was due to the fact that it was a first GA release and we just flat out got it wrong. It then took a few more rather quick releases to get it finally right. RTC for that period of stabilization may have been valuable, but since stabilization was achieved, it is just getting in the way of community involvement and ennovation. Brad >>> [EMAIL PROTECTED] Wednesday, November 17, 2004 12:42:08 PM >>> On Tue, Nov 16, 2004 at 06:10:17PM -0700, Brad Nicholes 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. Looking through the STATUS file, there doesn't actually appear to be much backport stagnation at all. The majority of stale backport proposals are stale because they are pending updates from the submitter after review by others, or they have been vetoed by a reviewer. Which is all healthy. So what's the evidence that there is a slowdown of activity caused by the backport policy? There have been four 2.0 releases already this year, including 179 individual user-visible changes listed in CHANGES according to grep. Sounds pretty healthy to me. Regards, joe
