From owner-freebsd-stable Wed Jun 27 12:13:54 2001 Delivered-To: freebsd-stable@freebsd.org Received: from c576194-a.saltlk1.ut.home.com (c576194-a.saltlk1.ut.home.com [65.5.60.246]) by hub.freebsd.org (Postfix) with SMTP id D6C8737B401 for ; Wed, 27 Jun 2001 12:13:47 -0700 (PDT) (envelope-from mupi@mknet.org) Received: (qmail 1120 invoked from network); 27 Jun 2001 19:13:46 -0000 Received: from localhost (HELO mukappa.home.com) (127.0.0.1) by localhost with SMTP; 27 Jun 2001 19:13:46 -0000 From: Mike Porter Reply-To: mupi@Mknet.org To: Bill Moran Subject: Re: Staying *really stable* in FreeBSD Date: Wed, 27 Jun 2001 13:13:45 -0600 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="us-ascii" Cc: "'freebsd-stable@freebsd.org'" References: <01C0FEFE.8EB2BA80.wmoran@iowna.com> In-Reply-To: <01C0FEFE.8EB2BA80.wmoran@iowna.com> MIME-Version: 1.0 Message-Id: <01062713134503.00453@mukappa.home.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wednesday 27 June 2001 09:44, Bill Moran wrote: > Is there a reason why you took this off the list? > my mistake (or my mailer's depending on how you look at it). If the majordomo config file for the list included the line "reply-to: stable@freebsd.org" then all replies would by defualt go back to the list. While this isn't ALWAYS appropriate, it usually is.... > This particular model falls apart when you have the FreeBSD development > model. Reasons: > 1) anyone who wants to test -CURRENT can, thus it doesn't fit typical > expectation of "alpha" Although depending on your circle of friends, it is frequnetly possible to get alpha-level stuff. More so from some places than others. However, according the handbook, "FreeBSD-CURRENT is, quite literally, nothing more than a daily snapshot of the working sources for FreeBSD." and "FreeBSD-CURRENT is made generally available for 3 primary interest groups: 1.Members of the FreeBSD group who are actively working on some part of the source tree and for whom keeping ``current'' is an absolute requirement. 2.Members of the FreeBSD group who are active testers, willing to spend time working through problems in order to ensure that FreeBSD-CURRENT remains as sane as possible. These are also people who wish to make topical suggestions on changes and the general direction of FreeBSD. 3.Peripheral members of the FreeBSD (or some other) group who merely wish to keep an eye on things and use the current sources for reference purposes (e.g. for reading, not running). These people also make the occasional comment or contribute code." Item 1 is clearly developers, and thus traditionally falls under "alpha" any way you slice it. Number 2 is perhaps more of a stretch, but even alpha testing implies that some testing is done. Opening up the "alpha" test to more people doesn't necessarily make it not an alpha test, it simply makes the results more accurate. The more mistakes/bugs/problems you can catch before the beta-test stage, the less problems you will have in beta. The less beta trouble you have, the quicker you can release a product. > 2) the developers are generally also the users I don't necessarily see the relevance of that to testing. If anything, it means the tests will be somewhat more thorough, but again, when the developer is the user, the user will use the product as intended, and may never break something. When an end-user is the user, who doesn't know what the underlying data structures are, if the program isn't smart enough to compensate for a stupid user, the user is going to make the program crash. Again, I would point out that in many cases, yes, this is simple user-error, and should not necessarily be the job of the developer to fix stupid users (as my brother-in-law, a programmer, used to call those errors "User Headspace Error"). > 3) The -STABLE branch is not *intended* to be for testing purposed only. It > is *intended* to be a useable product. In the commercial world, a "beta" is > NOT INTENDED for regular use, but for testing only. Thus, renaming the > -STABLE branch would be a misnomer. > I don't necessarily recommend renaming things (especially when the current (no pun intended) naming scheme works fine for most people) I think the perception should perhaps be clarified becuase -stable isn't nearly as stable as one would understand from either the handbook pages or the name. The simplest solution would be to equate -current with "alpha" code and stable with "beta" > > Of course, if you assume that STABLE is BETA level code, then you can > > expect some glitches, and sometimes things WILL slip through the cracks > > and cause major headaches...but *in general* you should have fairly > > stable code, with a few bugs in it. You EXPECT (or SHOULD EXPECT) there > > to be bugs in it....that's part of the development effort. > > No, according the the handbook, you should not *expect* there to be bugs in > -STABLE, You should be wary, as the handbook warns you, but my experience > with -STABLE over the last two years is that it's generally pretty > reliable. The handbook also states that you should subscribe to the stable > mailing list if you intend to track -STABLE, so anyone following the > hanbook is going to be well informed when breakage occurs. > hmm...maybe we are reading different versions of the handbook? "FreeBSD-STABLE is our development branch for a more low-key and conservative set of changes intended for our next mainstream release. Any changes to this branch will have debuted in FreeBSD-CURRENT first, helping to reduce (but not eliminate) the chance that the changes will cause problems" (from the online handbook) note the "but not eliminate" phrase. There is the expectation that the code should be relatively bug free (since it has been through one set of tests already) but one set of testing isn't necessarily enough. There *will* be problems (as you pointed out in your comments you will be "well informed *when* breakage occurs." (emphasis added, in case anyone's keeping track). I agree, I haven't been tracking stable very long, and I have had no real problems with it except a couple of software compatibility issues (newer versions of whatever shared library sometimes breaks something compiled with a different one....but that's not really the fault of stable, either, at least not entirely). and upgrading a binary while it is in use can have odd consequences (but that was my fault for not following updateing and booting to single user mode, and easily corrected, too) Although I tend to agree with you that the alpha-beta-release model isn't a perfect fit with the freebsd development model, I think it is pretty close, and those are terms that everyone pretty much understands these days who uses computers. If pressed, I would say that current straddles the line between alpha and beta testing, and stable is more or less late beta towards early release candidate level code, when compared to most commercial software. > I believe the recent changes to the handbook did an excellent job of > clearing this up. > I agree, but I think that putting things in terms people can understand is also important, and mentioning something along the lines of the above paragraph might help some people better undrstand the relationship between -current, -stable, and -release. On the other hand.....I seem to recall the initial post in this sub-thread was something like "if we are taking votes...." 1) I don't think we really are taking votes and 2) even if we were, I think the majority by their failure to chime in is indicating their general pleasure with the status quo. well, back to my day job.... mike > -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message