httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: 2.0.26?
Date Thu, 30 Aug 2001 13:57:12 GMT
On Thursday 30 August 2001 06:38, Bill Stoddard wrote:
> > 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.

And it would go a long way towards pissing off our testers.  We have people
who download the tarball when we release it, and if we replace that tarball
after just a few hours, then we are basically telling them that we don't need
their input, and they are only useful if they actually follow new-httpd, which
I think we all know is INCREDIBLY hard to do most days.

tag and roll and test.  If that one isn't good enough, then we do it again a week
later.  We would easily get to a beta or production release, if we didn't keep
changing the internals of the server, or if we posted large patches before
they were committed, or if people ran the httpd-test/perl-framework test suite
before committing, and if people would write tests once they fix a bug.  The
problem we have right now, is that most people don't use the test-suite, so
even though it is catching most of the bugs when they are committed, nobody
knows it.


Ryan Bloom
Covalent Technologies

View raw message