Lazy backport on 2.0 make it less stable, working for 2.1 is not really exciting because nobody or really few people use it.
The new auth layer in 2.1 is better than 2.0, inside 2.1 for a long time now, but not popular as it should be.
I think 2.1 is not public enough
Actually, i think people don't take time to use cvs + cvs on apr and apr-util, or don't take time to find snapshot to use 2.1. They also don't telnet apache.org to look what we are running. They go on httpd.apache.org, follow download link, and take 2.0.
A good solution would be to schedule some snapshot based on time (time is impartial and we will not fall in unfinished discussion) and some release based on dev and stability, and communicate more on these new features and enhancement
Regards,
Matthieu
Jeff Trawick wrote:
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 discussLooking through the STATUS file, there doesn't actually appear to be
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.
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.
