httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: stable 2.0 trees
Date Tue, 15 Oct 2002 13:52:32 GMT
At 08:16 AM 10/15/2002, Bill Stoddard wrote:
>> After a million messages on related topics, I'm not sure that any two
>> developers agree on all of the following topics:
>> . how much to consider the needs of users relative to desires of
>>   developers
>> . how hard to try not to break binary compatibility
>> . how much to use 2.0 HEAD as a sandbox for new features
>> . whether or not to start 2.1 now for auth changes
>> Meanwhile, a number of the 2.0 users which have dared poke their heads
>> into our mailing list point out through their comments that we have a
>> PR problem (regardless of whether or not you agree technically on
>> their particular concerns).
>Worth reading...
>I am generally in favor of maintaining a binary compatible/stable 2.0 cvs
>repository. I think this may help the third party module authors to finally
>do the work to get their modules running on Apache 2.0, which should help
>improve the 2.0 adoption rate.  What we call that repository is not
>particularly important to me, though the name we choose may have PR
>implications which we should be sensitive to.  My suggestion is we freeze
>2.0 MMN major bumps (unless there is a really, -really-, REALLY compelling
>reason to do a bump) and start a new development tree for 2.1. Lets set some
>goals for what we (the developers and the user community) want to see in 2.1
>and work toward those goals (ie, finish and agree on the ROADMAP we've
>already started).

I have to concur with Bill on this (in spite of the fact that Jeff's arguments
try to appeal to everyone's sensibilities.)  I think the new proposal, that we
have a maintenance tree stemming from Apache 2.0.43 using 
sub-subversions, follows from the fact that the list has been unresponsive
to using revisions by the usual definitons.

My question is just this... why do we feel that every revision must be
'completed'?  Clearly, 2.0.x is new territory.  Many will never upgrade 
to any 2.0.x simply because of the magic .0. in the middle.  And this
magic .0. has been GA for over six months.

We got to 2.0 GA only because of tons of effort by many enthusiastic
hackers.  Right now, there is no place for such individuals to express
their creative energy in improving the project, unless they want to get
mired down in debates between breaking modules or configurations.

It seems that the 'maintainers', the stodgy 'old men' of the group, want
everyone to row together on bug fixes.  That isn't how OS works.  The
folks with no interest in tracking down obscure bugs just leave, or
quietly bide their time.  The number of commits to the project is way
down, meaning the rate of improvement for the project has slowed.

Some folks are primarily focused on new development and ideas.
Others are primarily focused on cleaning up functionality.  Some
have few interests outside of cleaning up grammar and legibility.
And some want little more than to shape the architecture of
the server, coding is simply a means to that end, for performance,
scalability, security, etc.  All of these are worthwhile contributions
if done in the right context.

Jeff especially hit one nail on the head;

>. let those who are interested (not more than a few would be needed to
>  make it viable) maintain a separate tree based on 2.0.43, including
>  apr and apr-util...  call it httpd-2.0.43, with potential releases
>,, etc.

Dropping the sub-subversion discussion for the moment, he hit on 
the magic words "let those who are interested".  Those who want to 
maintain stable will, it's their itch.  Those who want to make forward 
progress on the alpha/beta tree will have that outlet.

I have an interesting idea about resistance to stability.  Perhaps it's
nothing less than immediate gratification.  Most anyone who writes 
code wants users to adopt that code, the quicker the better. When
the new code is the "right way"(R) we want people to immediately
quit doing things the 'wrong way'.  But 1.3 shows us that our end
users don't always adopt the "right" code quickly.

What's the penalty for stable/development trees?  Users don't have
the development code (at least not many) for some time, until the
development tree becomes GA quality.  But that's how it should be,
and that's the only way we will ever find 1.3 adopters moving to 2.x.
Anyone solid code contributions that don't break the API can always
be merged back to the GA maintenance tree.  We've done that for
two years from 2.0 to 1.3, and it's worked.


View raw message