httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: the wheel of httpd-dev life is surely slowing down, solutionsplease
Date Thu, 13 Nov 2003 00:07:20 GMT
On Tue, Nov 11, 2003 at 09:55:24AM -0700, Brad Nicholes wrote:
> One question: Have we set the barrier too high? This was discussed at
> length last year when the 2_0_BRANCH was created and I think that it is
> worth reviewing.  My personal feeling is that the barrier may be doing
> more to discourage development and patch submission than it is to avoid
> breaking the code.  Should the barrier be relaxed to a certain extent? 
> When a patch is submitted to the 2_0_BRANCH, isn't the most important
> question to be asked, does it break backward compatibility?  If the
> answer is no, then why not commit it?  Is there any other reason to hold
> a patch (bug fix or enhancement) over in the 2.1 branch?  There is a
> growing list of backports in the 2.0 STATUS file and although I haven't
> reviewed them all personally, my guess is that the majority of them
> won't break backward compatibility otherwise they wouldn't have been
> proposed.  
> 
> People like to see the results of their work.  This is true whether it
> be software development or fixing the kitchen sink.  To my knowledge
> there has never been a release of the 2.1 branch therefore much of the
> work that is going on there is going unnoticed.  This includes bug fixes
> as well as new features.  Yes, you can say that people can just pull the
> code from CVS, but what percentage of potential testers pull the code
> from CVS vs. download a tar ball?  If developers are allowed to see the
> results of a patch that they submitted, they are much more likely to
> submit another one.  
> 
> The current R-T-C policy in place over the 2_0_BRANCH prevents
> otherwise good patches from making it into the code in a timely fashion.
>  I have a proposed backport that has been sitting there for weeks with
> only a 0 vote placed on it.  I understand that relaxing the R-T-C policy
> may allow for a certain degree of destabilization, but isn't it faster
> to find a bug in code than it is to find it in a description of proposed
> patch.  Also, the people that seem to be reviewing the patches, appears
> to be the same set of people which tends to say that there are fewer
> eyeballs on a patch rather than more.
> 
> IMO, the faster we get patches in front of the masses, the faster bugs
> are fixed and stabilization is acheived.

+1

I feel we should bring the barrier to entry as low as possible, and
right now the bar is too high. I would be in favor of going back
to CTR on 2.0, and letting the incompatibilities and bugs sort
themselves out with our beta testers (who, mind you, are completely
willing to play with the latest and greatest and would be happy to
submit bug reports).

-aaron

Mime
View raw message