httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject versioning process
Date Tue, 05 Feb 2002 02:02:22 GMT
> I know that there have been lots of changes in .32-dev since .31 was
> tagged that have challenged the stability of the current tree.  If
> we took .32 and made it as close to .31 as we could but with the
> *minimum* required changes to make .32, we could be close to a real
> beta.  (This seems to mimic the APACHE_BEST tag I think was proposed
> before my time.)

Actually, that one was during your time.

The fact of the matter is that the RM doesn't even need to tag the tree.
If they *really* want to test a configuration (set of revisions) on all
platforms, then simply checkout HEAD (or whatever) and work within the
checked-out tree, avoiding the use of cvs update except for specific file
changes.  A -dev tarball can be created (with whatever non-version name
you want to give it) from the checked-out tree, which can then be tested
by people with access to the other platforms.  Only after they come back
with a +1 is the checked-out tree tagged with the next version number,
which impacts only those revisions in that tree and not whatever has
happened to HEAD.

I mention this every time the release process is argued:
it is the responsiblility of the RM to tag a version of the tree that
they *think* is stable.  How they come to think that will entirely
depend on how much time, energy, and resources they can throw at the
code *before* it is tagged with a version number.  They can do that
by managing a checked-out tree or by using a temporary non-version tag
to manage a branch of the real tree -- either one is better than tagging
the tree with a public version number and them moving that tag around to
suit the testers.  Once it is tagged with a version number, we need to
simply live with the fact that the version number is HISTORY and stop
arguing about whether one change or another should be included.

BTW, the version number means

   major.minor.patchlevel

After the group spends enough time pounding on a release to call it GA,
there is no reason why we cannot take the code and reversion it a 2.1.0
and start treating that as the stable branch.  It may be a little
confusing to the Linux folks, but we can always skip to 2.2.0 if that
makes people happier.  Personally, I tend to think that even-numbered
releases are less reliable than odd ones, because that has been my
experience with the quality of commercial releases.

And, personally, I have always hated the stupid alpha/beta/GA distinction.
Our release process became constipated on the day that was added.

I guess the point is that we shouldn't let the process of tagging the
tree interfere with getting a complete-revision-set of the server that
is stable enough for a release.  There is really no reason (aside from
a desire to get three +1 votes) for the RM to need to coordinate with
everyone else in the group when a release is ready to be tarballed, nor is
there any reason (aside from the release votes) for the RM to include
everything on HEAD when they do tag a release version.  The only thing
that is really necessary is that the final tarball has at least three +1 
(and a majority positive) before it is placed in www.apache.org/dist/httpd/.

If I were the RM, I'd just work in a tree of relatively stable code and
tag the version when I bloody well felt like it was good enough to stake
my reputation on as being better than the last version released.  No, I don't
have time to be an RM right now.  OTOH, there is also very little reason
why we can't have multiple RMs working in parallel, provided they work
with private tag names and let the group decide which tags to promote to
an official version.

Of course, the real problem is that httpd developers these days just have
it too easy.  When I was an RM, we had to get up at 4am and walk through
snow in our underwear in order get enough carrier pigeons together to
distribute a tarball, and then wait a week for enough pigeons to
come back alive to count it a release.  When it's that hard to do a release,
the RM spends a lot more of their own time proofing a tarball before it
gets out, and makes a habit of doing a release before there are more than
30 or so changes since the last one, because the probability of that
many changes being error-free is approaching zero.

I think people just respect the process too much.  We are here to maintain
and release code -- the process only exists to allow us to get there without
killing each other.  If it isn't working, determine the part that doesn't
work and replace it with something new.  The only things that you cannot
replace are that code must be committed before it is released and the
tarball must be voted on before it is released to the public.

....Roy


Mime
View raw message