Date: Wed, 16 Oct 1996 10:40:08 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: rkw@dataplex.net (Richard Wackerbarth) Cc: freebsd-hackers@FreeBSD.org Subject: Re: IP bugs in FreeBSD 2.1.5 Message-ID: <199610161540.KAA27811@brasil.moneng.mei.com> In-Reply-To: <v01540b00ae8aa9b6cd6d@[204.69.236.50]> from "Richard Wackerbarth" at Oct 16, 96 09:15:08 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> I generally agree with your approach. However I would suggest that not > >> 2.1.5, but 2.1.x is the appropriate one for production. > > My point here is that, although few changes have been made, we should > encourage people to upgrade from 2.1.5R to the present "-stable". I can see arguments both ways. I do not disagree with the idea, but for people to upgrade from 2.1.5R to 2.1.6R with a very small delta (particularly if it consists of changes that do not affect them) may not make sense. I do not particularly care, I simply want to see some variant of this "well tested" branch to stay around until there is a 2.2 based "well tested" branch. > >What is wrong with the ALPHA/BETA/RELEASE cycle (aside from the fact that > >it has been pretty much abused/ignored for the last few releases)? > > "Pretty much"? I feel that it has been totally abused. I was being kind. > >Some of us are quite willing to test 2.2ALPHA if one is made available. > > In a sense, the "SNAPS" are "Alpha". The primary thing missing is the > initial effort to define the release's feature target. I agree that the SNAP's have been used as "Alpha" - and "Beta" - and "Gamma" too. (2.1.0-951026-SNAP, should have been 2.1.0GAMMA) If you are saying that this is acceptable as an alternative to a formal release procedure (and I do not think that you are trying to say this), I would very much disagree. > My point was that we SHOULD a reasonable amount of "shaking out" BEFORE we > drop the "RELEASE" label on something. Oh, ABSOLUTELY! But I do not think it is unreasonable to let something out the door that may be somewhat less stable than a previous release, just like 2.0R was not as stable as 1.1.5.1R. I ABSOLUTELY think it needs to go through a full cycle release. > >However, I personally feel that in order to produce a more robust 2.2.5R, > >several months of beating on 2.2R will be necessary, and this is NOT going > >to be possible if the core team has a goal of December in mind for 2.2R. > > > >I would prefer to have a 2.2ALPHA in my hands TODAY, a 2.2BETA a month > >from now, followed by a 2.2R in December. This would shake out obvious > >bugs in 2.2R, but would not be a sufficient period of time for robustness > >testing and bug elimination. > > I concur. I also feel that we should continue to "support" (as in "have > readily available") a production grade version that has been shaken pretty > well. This is a commendable goal, but it remains to be seen whether or not it is possible to do so in a practical manner. With the energies of the core team focused on -current, and distracted by 2.2-stable, I suspect that the issue of "support" beyond just having the 2.1.6R version available will be sticky. Having the version available for download is, of course, trivial. > If we have gone through the ALPHA/BETA/RELEASE cycle, then the "its in the > new (but unproven) release" is a reasonable answer to feature problems. I concur. > >But... when it comes right down to it, I don't care too much about how > >it's numbered, I just want to see something happen. :-) > > I do think that numbering has some impact on the perception that the public > has of the product. Sure it does, but I do not want to see FreeBSD inventing numbering schemes simply to impress the public. ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610161540.KAA27811>