Date: Wed, 27 Jun 2001 13:13:45 -0600 From: Mike Porter <mupi@mknet.org> To: Bill Moran <wmoran@iowna.com> Cc: "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org> Subject: Re: Staying *really stable* in FreeBSD Message-ID: <01062713134503.00453@mukappa.home.com> In-Reply-To: <01C0FEFE.8EB2BA80.wmoran@iowna.com> References: <01C0FEFE.8EB2BA80.wmoran@iowna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01062713134503.00453>