Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 Apr 2001 14:15:22 -0400 (EDT)
From:      "David A. Koran" <dak@solo.net>
To:        <dan@langille.org>
Cc:        <jkh@osd.bsdi.com>, <stable@FreeBSD.ORG>
Subject:   Re: Releases
Message-ID:  <1214.209.141.226.130.986840122.squirrel@www.solo.net>
In-Reply-To: <Pine.BSF.4.32.0104100555590.38514-100000@xeon.int.nz.freebsd.org>
References:  <Pine.BSF.4.32.0104100555590.38514-100000@xeon.int.nz.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Dan (and all),

	Jordan does have a point though. I've noticed that there are a lot of
people delving into CVSup'ed updates way before really understanding the
consequences of what being "up to date" can cause. Jordan's point about the
CVS tree and development always being in a state of flux holds very true and
anybody willing to try to keep up should be aware of that fact. Now,
obviously there is an argument for when CVS has major bug fixes and security
patches, but at least for the security side of things, the SA's usually
offer a patch diff file that can be applied to the source to fix the hole.If
anybody plans on keeping on the "bleeding edge" (granted not following
-CURRENT) they should know that depending on when they CVSup their tree,
they get different snapshots. A solution, for those that seem to need their
releases, is to truly do "snapshots" the way many ports get their sources
(Postfix, Cyrus, etc.). I know the whole RC idea and BETA labelling gets
people confused at times, but if you notice the build has those labels, you
may want to think twice about typing the "make installworld" command. There
are a lot of shops that will only run releases, and will only upgrade to
their own "snapshots" after a load of internal testing. A possible offering,
is to have some of those shops offer some of their own certification (via a
TEXT document specifiying what works and what doesn't during a snapshot
release) that a given release works and give back to community. Unless their
is a formal QA process followed or FreeBSD sets up a testing lab, this is
probably the best we can hope for.

David A. Koran


> On Mon, 9 Apr 2001, Jordan Hubbard wrote:
> 
>> > Just because the problem is difficult to solve does not mean it can
>> > not be or should not be solved.
>>
>> Fine, how about you solve it and the rest of us will get back to all
>> the other stuff we have on our plates. :)
> 
> OK.  But if you didn't want to be involved in the first place, you
> should have stayed out of it.
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message



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?1214.209.141.226.130.986840122.squirrel>