httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: 2.0.26?
Date Thu, 30 Aug 2001 19:27:08 GMT



> From: "Bill Stoddard" <bill@wstoddard.com>
> Sent: Thursday, August 30, 2001 11:55 AM
>
>
> > Not really. The process Cliff and I outlined is really aimed at getting -a- stable
release
> > available. The process will take at least 2 days to go through but shouldn't take
more
> > than maybe 4 days total. If we use this process AND use your suggestions to not
commit
> > huge chunks of untested code during our 'stabilization period' I am confident we
can
get
> > stable releases out on almost every try. We can control the release of tarballs
to the
> > test community.
> >
> > And what is the point of having testers spend time on a release that we know is
broken?
> > Isn't it better to just tell them "hey don't waste your time on this tarball"?.
OTOH...
> > what rule says that testers must test each and every tarball? If a tarball (even
an
alpha
> > tarball) works well enough, the testers can still find and report bugs that we havent
> > discovered yet.
> >
> > One other question... have you received complaints from testers about the frequencey
of
> > our tarball updates?
>
> Keep in mind one key detail, our most _active_ testers are using cvs (even on win32 ;)
>
>
>
> > I don't think we are currently using the model suggested by Roy. I believe Roy's
model
is
> > closer to what Cliff and I are advocating. With one exception... The exception is
that
> > some of us believe a 'feature freeze' (or 'big code change freeze', whatever you
want
to
> > call it) needs to go into effect during the 'stabilizing period'.  I know Roy doesn't
like
> > this idea but I see no other way out of our current inability to get stable releases.
>
> There is no such need.  Tag.  Roll in or out the changes that get a particular version
> stable.  We have CVS.  Use it.
>
>
>
> > > Yep.  :-)  But we also need to stop committing every possible change immediately.
> >
> > +1. Announce when we are in the 'stabilization period' and discourage (prohibit?
:-)
big
> > commits during the period that do not enhance stability.
>
> My other post suggests we simply follow R-T-C (with a strict 3 +1's except on obscure
> build maintenance by platform maintainers) on a tagged branch.  There's no need for this
> in the main tree.
>
> See my post to rbb for the rest of my thoughts on this personal slight,
> you are certainly impliciated as well.
>

No slight intended, personal or otherwise.  Big code drops going in right as we announce a
tag & roll is normal. It happens -every- time and most of us have been the perps at one
time or another. This is pretty normal in closed source development shops as well when
trying to hit driver dates.  Everybody has code that -must- go in or the release will just
be totally hosed (in their mind :-).

We clearly have a problem getting stable releases out and I'm interested in solving the
problem, not pointing fingers.

Bill


Mime
View raw message