You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2002/10/15 15:01:00 UTC
stable 2.0 trees
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).
I would like to propose the following:
. let 2.0 HEAD proceed as it seems to be going now... maybe not
everybody is happy about every aspect but the way it is handled is
rough consensus of developers... I'm not saying this is wrong, but
I think that the volatility of 2.0 HEAD + APR HEAD is high enough
that it is hard to put out a good release quickly unless we're very
conservative and put something out with just a couple of changes
beyond 2.0.43
. 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
2.0.43.1, 2.0.43.2, etc.
priorities would be
. quick integration of critical fixes from HEAD
. skepticism regarding any changes other than critical fixes; for
some fixes it would be best to wait to see if any users of the
stable tree actually encounter the problem
. maintaining the MMN
starting this now would let folks with modules from 2.0.41-2.0.43
continue to work into the future, even if they need to pick up a
security fix in Apache, even if 2.0 HEAD needs to bump MMN
tomorrow
When it becomes impractical to achieve these goals with 2.0.43 code
(e.g., a critical problem can't reliably be fixed without bumping
MMN), then it is time to discard this particular stable tree and
tell folks to move to the current release to get new fixes. If
there are still concerns about volatility in 2.0 HEAD at that point
then there will be a need for another stable tree.
Note: There are ways other than a separate CVS tree to implement the
same objective. Rather than pick on the mechanism, the first order of
business is to address the ability for some of us to make releases
with such a conservative set of changes. Then we (hopefully comprised
mostly of people who plan to do the work) can worry about how it
should be done.
(grabbing flak jacket)
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: stable 2.0 trees
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
i'm responding to the head of this thread because i haven't read
the rest of it yet.. so, as usual, my comments may be stale.
Jeff Trawick wrote:
>
> . let 2.0 HEAD proceed as it seems to be going now
:
> . 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
> 2.0.43.1, 2.0.43.2, etc.
>
> priorities would be
>
> . quick integration of critical fixes from HEAD
>
> . skepticism regarding any changes other than critical fixes; for
> some fixes it would be best to wait to see if any users of the
> stable tree actually encounter the problem
>
> . maintaining the MMN
this works for me, except for some of the details -- like the
version nomenclature.
let's get away from the term 'branch', and use something less
technically overloaded. i propose 'stream'.
i'd like to combine this with the leap-frogging stable/development
stream idea. for stake-in-the-ground and pr reasons, i'd suggest
taking whatever we want to start this stable stream with and
giving it a new number, such as 2.1. (i suspect i'm anticipating
firstbill's probably-already-posted comment on this..) then rename
head to 2.2 and that's where development continues. 2.0 as such
dries up and blows away. when we repeat with a new stable stream,
the 2.2 head gets snapshot as 2.3, head becomes 2.4, and 2.2 vanishes.
whew, that's a load off the top of my head.. :-)
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
Re: stable 2.0 trees
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@apache.org> writes:
> 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.
just curious... which proposal corresponds to "want everyone to row
together on bug fixes"?
> 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
> > 2.0.43.1, 2.0.43.2, 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 would expect that anybody working on maintaining the extremely
stable release would be involved with the alpha/beta tree too, since
the very definition of the extremely stable release (only critical
fixes always close to release-able since there aren't many changes to
test) means that there isn't much work associated with it.
Bill S and I had some discussions over lunch which make me suspect
that I'm not communicating very well the spirit of what I proposed.
First, I'm pretty happy with what is going on in 2.0 HEAD now. I
don't think MMN is changed gratuitously, I don't think the code gets
destabilized a whole lot on a regular basis, I think that having some
aspects of the config change (i.e., the auth issue) change at this
point in the >=2.0 lifetime is not completely unreasonable (scripts
can certainly help admins). I think we're still at a point where
changing MMN is reasonable under certain conditions.
My proposal was just to allow extremely conservative/stable releases
which any current 2.0 site could upgrade to with no fears (either of
new Apache problems from some of the itch scratching or breaking
compatibility with 3rd party modules) in order to pick up a fix for a
security problem they're concerned with.
This proposal wasn't intended to address the big picture of how
overall development proceeds and which changes can be delivered within
2.0 framework or some new set of ideas. It was only to calm the
concerns of sites running 2.0 which have things working pretty well
but are concerned that the 2.0 tree has enough activity that they risk
breaking something else by picking up a new 2.0 release.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: stable 2.0 trees
Posted by gr...@apache.org.
"William A. Rowe, Jr." wrote:
> 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.
+1 on the concept of a stable 2.x release, where x > 0. Bill S. has good points
about the PR aspects of release numbers. I'm sort of leaning toward x being
even since that fits in with what many folks are used to.
I wouldn't mind being a stable release maintainer. It would be very satisfying
to help drive up user acceptance of 2.x, plus I'm a stodgy old man of course.
I'll want to play in the itch scratching tree occasionally too.
Greg
RE: stable 2.0 trees
Posted by Jeff Stuart <js...@computer-city.net>.
On Thu, 2002-10-17 at 00:49, Justin Erenkrantz wrote:
> I'd prefer to come up with strict versioning rules for httpd before
> proceeding further. I'm slightly concerned that we're starting to
> move away from the 'versions are cheap' ideology. Currently, we
> place no meaning on the version numbers (only the quality of the
> tarball). I think we ought to step back and place a meaning on the
> versions first. -- justin
Just speaking as an end user here, the idea that versions are cheap just
seems wrong to me. Why? I can't explain it. :) BUT I'm MUCH more
comfortable with knowing that 1.3.27 is a RELEASED version of apache vs
2.0.44 was not released and so we went to 2.0.45. I think that if we
followed either the perl/linux kernel module of release numbers and
pre/rc scheme as others have said, that makes sense.
What does a version number mean? Well, in the even numbered release
that the server is STABLE and it fixes bug(s)/adds MINOR features. Also
that I as a admin can upgrade apache to apply the latest fix WITHOUT
HAVING to recompile my other modules. Ala the 1.3 tree.
--
Jeff Stuart <js...@computer-city.net>
RE: stable 2.0 trees
Posted by Justin Erenkrantz <je...@apache.org>.
> At the risk of racing too far ahead in this discussion, here is my
> suggestion... 2.0.43 becomes 2.1 and the MMN major does not change
> for subsequent 2.1 series releases (except for a compelling reason,
> eg a security fix -requires- a bump). Why 2.1? No technical
> reason; purely a PR tactic to telegraph to the user community we
> are putting a lot of focus on maintaining binary backward
> compatability and to get rid of the *.0.* in the version number
> (yea, to appease the folks who are allergic to 0's in version
> numbers).
Here's my fundamental concern: where do we do the bulk of development
(new features)? Do we no longer have 2.0 releases? Do we close 2.1
to new features (only security fixes)? More precisely, who dictates
what goes into 2.1 or 3.0?
If the sole criteria is MMN bump, the auth changes didn't cause a
bump of the MMN. So, then, does it belong in 2.1? When can we
remove (or rename) a module - is that a version bump? What if we add
a module - version bump? What if APR changes a function prototype -
does that require a version bump? What if we change the meaning of a
directive (say TAKE12 to TAKE1)? What if we add (or delete) a
directive?
If we decide to split off 2.0 into two trees (2.1/3.0 as you
suggest), then what is the criteria for 3.0 supplanting 2.1? What is
the expected lifetime of 2.1? What is the expected lifetime of 3.0?
Should we expect a 2.2? What is the policy for backporting fixes?
What is the policy for forwardporting fixes? (Surely no one can
suggest that 2.0 is bug-free.) Do you wish to allocate resources for
maintaining each branch (a la Linux which has open 2.2/2.4/2.5 trees
and a dedicated maintainer for each)?
I'd prefer to come up with strict versioning rules for httpd before
proceeding further. I'm slightly concerned that we're starting to
move away from the 'versions are cheap' ideology. Currently, we
place no meaning on the version numbers (only the quality of the
tarball). I think we ought to step back and place a meaning on the
versions first. -- justin
Re: stable 2.0 trees
Posted by Cliff Woolley <jw...@virginia.edu>.
On Wed, 16 Oct 2002, Aaron Bannert wrote:
> > I like.
>
> I also like, but I also think we should stick with the "even numbered
> revisions are stable, odds are developmental" axiom.
Definitely agreed.
--Cliff
Re: stable 2.0 trees
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Oct 15, 2002 at 10:22:46AM -0400, Jim Jagielski wrote:
> Bill Stoddard wrote:
> >
> > At the risk of racing too far ahead in this discussion, here is my
> > suggestion... 2.0.43 becomes 2.1 and the MMN major does not change for
> > subsequent 2.1 series releases (except for a compelling reason, eg a
> > security fix -requires- a bump). Why 2.1? No technical reason; purely a PR
> > tactic to telegraph to the user community we are putting a lot of focus on
> > maintaining binary backward compatability and to get rid of the *.0.* in the
> > version number (yea, to appease the folks who are allergic to 0's in version
> > numbers).
> >
>
> I like.
I also like, but I also think we should stick with the "even numbered
revisions are stable, odds are developmental" axiom.
-aaron
Re: stable 2.0 trees
Posted by Jeff Stuart <js...@computer-city.net>.
On Wed, 2002-10-16 at 02:23, Jeff Stuart wrote:
> Not to make a me too post BUT.. me too. I've been using apache 2. on
> non critical projects or where I MUST use apache 2. (IE Subversion
> repository). So far, it's stable BUT (and I stress this HIGHLY) it's
> not been pounded on AT all. IE at most, 100 hits in a day by 3 or 4
> people AT most! :)
This is what happens when I hit send to quick! I meant to say "It's not
been pounded on AT all by me.". IE While I THINK it's OK.. I don't have
that warm fuzzy feeling about Apache 2. (Yet. :))
--
Jeff Stuart <js...@computer-city.net>
Re: stable 2.0 trees
Posted by Jeff Stuart <js...@computer-city.net>.
On Tue, 2002-10-15 at 10:46, Thom May wrote:
> * Jim Jagielski (jim@jaguNET.com) wrote :
> > Bill Stoddard wrote:
> > >
> > > At the risk of racing too far ahead in this discussion, here is my
> > > suggestion... 2.0.43 becomes 2.1 and the MMN major does not change for
> > > subsequent 2.1 series releases (except for a compelling reason, eg a
> > > security fix -requires- a bump). Why 2.1? No technical reason; purely a PR
> > > tactic to telegraph to the user community we are putting a lot of focus on
> > > maintaining binary backward compatability and to get rid of the *.0.* in the
> > > version number (yea, to appease the folks who are allergic to 0's in version
> > > numbers).
> > >
> >
> > I like.
> >
> Me too.
>
Not to make a me too post BUT.. me too. I've been using apache 2. on
non critical projects or where I MUST use apache 2. (IE Subversion
repository). So far, it's stable BUT (and I stress this HIGHLY) it's
not been pounded on AT all. IE at most, 100 hits in a day by 3 or 4
people AT most! :)
--
Jeff Stuart <js...@computer-city.net>
Re: stable 2.0 trees
Posted by Thom May <th...@planetarytramp.net>.
* Jim Jagielski (jim@jaguNET.com) wrote :
> Bill Stoddard wrote:
> >
> > At the risk of racing too far ahead in this discussion, here is my
> > suggestion... 2.0.43 becomes 2.1 and the MMN major does not change for
> > subsequent 2.1 series releases (except for a compelling reason, eg a
> > security fix -requires- a bump). Why 2.1? No technical reason; purely a PR
> > tactic to telegraph to the user community we are putting a lot of focus on
> > maintaining binary backward compatability and to get rid of the *.0.* in the
> > version number (yea, to appease the folks who are allergic to 0's in version
> > numbers).
> >
>
> I like.
>
Me too.
--
Thom May -> thom@planetarytramp.net
<spectra> Hello!
<spectra> What is the voting period? From Mar 24th until?
<asuffield> until the candidate manoj wants to win is in the lead
* asuffield ducks into the icbm shelter
RE: stable 2.0 trees
Posted by Bill Stoddard <bi...@wstoddard.com>.
> 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...
> >http://techupdate.zdnet.com/techupdate/stories/main/0,14179,28822
> 03,00.html
> >
> >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.
At the risk of racing too far ahead in this discussion, here is my
suggestion... 2.0.43 becomes 2.1 and the MMN major does not change for
subsequent 2.1 series releases (except for a compelling reason, eg a
security fix -requires- a bump). Why 2.1? No technical reason; purely a PR
tactic to telegraph to the user community we are putting a lot of focus on
maintaining binary backward compatability and to get rid of the *.0.* in the
version number (yea, to appease the folks who are allergic to 0's in version
numbers).
New ROADMAP development is started in 3.0.
Bill
RE: stable 2.0 trees
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
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...
>http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2882203,00.html
>
>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
> 2.0.43.1, 2.0.43.2, 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.
Bill
RE: stable 2.0 trees
Posted by Ask Bjoern Hansen <as...@develooper.com>.
On Tue, 15 Oct 2002, Bill Stoddard wrote:
> Worth reading...
> http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2882203,00.html
On October 2nd; *after* RedHat 8.0 was released he wrote "And I
doubt Red Hat will make 2.0 the default install until [...]".
Really Impressive Predictions.
- ask
--
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
RE: stable 2.0 trees
Posted by Bill Stoddard <bi...@wstoddard.com>.
> 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...
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2882203,00.html
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).
Bill