httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: 2.0.26?
Date Thu, 30 Aug 2001 13:38:27 GMT

> On Wednesday 29 August 2001 21:18, Justin Erenkrantz wrote:
> > On Wed, Aug 29, 2001 at 09:17:32PM -0700, Ian Holsman wrote:
> > > On Wed, 2001-08-29 at 20:22, Justin Erenkrantz wrote:
> > > > Should we be at 2.0.26-dev in ap_release.h?  -- justin
> > >
> > > should we re-roll&tar 26 (which would include a patch to worker and
> > > ldap_cache, some NW fixes and the apr-dbm change)
> > >
> > > or just re-tag the 2 files modified as 25 and re tar?
> >
> > We shouldn't re-roll 2.0.25.  We need to T&R 2.0.26 instead, IMHO.
> >
> > We also need the just-committed mod_mime fix.  I'll leave the
> > rolling to someone who has done it before (rbb?).  Try, try,
> > again.
> >
> > I'm verifying wrowe's commit right now.  It looks right.  =)
> > See if it works right...  -- justin
> We shouldn't do either.  If you go back and read the original thread,
> one of the general rules of this release strategy is that we don't release
> every day.  We just rolled a tarball, and announced it to the new-httpd,
> so there are people testing it at this point.  That tarball has to stand or
> fall on it's own.  In a week, we can re-roll 2.0.26, and try again.
> This, BTW, is why I originally stated that this release mechanism wouldn't
> work.  We keep on trying to improve the server, which means that people
> keep changing core parts of the server.  Either people need to stop
> doing that, and just focus on fixing bugs, or we all need to accept that we
> will be stuck with just one beta for a VERY long time.
> Ryan

Completely agree that our release strategy (with Dr. Evil quotes around strategy) is
broken.  But we should be able to tag the tree anytime, IMHO. If HEAD is good, I am for
tagging 2.0.26 and testing it but let's not roll the tarball. Fix any problems in 2.0.26
and bump the tag on affected files. When we are satisfied, roll 2.0.26. Put a time limit
on the whole process of say, 4 days. If the time limit is exceeded (showstopper problems
have not been driven out within 4 days of the tag) or the rolled tarball has showstoppers,
consider the beta effort a failure and move on.

This is basically what we did with 2.0.24 and it was almost successful. 2.0.24 dragged on
a bit too long (over a week) and we rolled a couple of different 2.0.24 tarballs, which
was not cool. Tagging a good HEAD, incrementally fixing showstoppers (provided the fixes
are relatively limited in scope and simple) and bumping the tag on affected files, and
exercising a little disipline and restraint for a few days (even just a few hours) prior
to our target for rolling a beta would go a long way to solving this problem.


View raw message