httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <>
Subject Re: the wheel of httpd-dev life is surely slowing down, solutionsplease
Date Tue, 11 Nov 2003 16:55:24 GMT
>> The worst part is that it's now easy to sneak in code which
>> would never be accepted (and backport it to 2.0). I don't have any
>> examples, but I think the danger is there.
>There is a barrier to getting things backported to 2.0 as a protection
>possible drawbacks of C-T-R.
>If three people are in favor of putting something in the stable
>mistakes can still happen, but I don't see how we can refer to such a
>as sneaking in code.

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

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.

Just my 2 cents as to why the httpd development may have appeared to


Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions 

View raw message