From owner-freebsd-hackers Wed Oct 16 08:41:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA09758 for hackers-outgoing; Wed, 16 Oct 1996 08:41:21 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA09744 for ; Wed, 16 Oct 1996 08:41:13 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id KAA27811; Wed, 16 Oct 1996 10:40:09 -0500 From: Joe Greco Message-Id: <199610161540.KAA27811@brasil.moneng.mei.com> Subject: Re: IP bugs in FreeBSD 2.1.5 To: rkw@dataplex.net (Richard Wackerbarth) Date: Wed, 16 Oct 1996 10:40:08 -0500 (CDT) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: from "Richard Wackerbarth" at Oct 16, 96 09:15:08 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >> 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