httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: 2.0.26?
Date Thu, 30 Aug 2001 18:07:48 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.

Bill


Mime
View raw message