On Wed, 17 Nov 2004 19:42:08 +0000, Joe Orton <[EMAIL PROTECTED]> wrote: > 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?
Yes, from current STATUS it looks like a few people (including myself) can take action on items which garnered sufficient interest, and everything else has some concerns to be considered. IMHO, better to address those concerns with zero impact to being able to put out a new stable release at arbitrary point in time than to commit stuff to "stable" irrespective of such concerns and have it forgotten about. If there is stagnation which is caused by the backport process, perhaps it is self-imposed by the folks who don't have time/inclination to go through the current deliberations which are required to get the changes they're shepherding into the stable branch? Is that it? Note that some "stagnation" issues are just that people (ME!!!) are in temporary binds with other responsibilities and can't put forth a lot of effort at present; handling these backports in such a deliberate manner allows some of us to put our limited time to good use -- keep up with the STATUS file and reviewing carefully identified patches. Not optimal, not a major reason behind the current backport mechanism, but useful side-effect nonetheless.
