Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 08 Sep 2003 12:48:37 -0700
From:      underway@comcast.net (Gary W. Swearingen)
To:        Brad Knowles <brad.knowles@skynet.be>
Cc:        freebsd-chat@freebsd.org
Subject:   Re: The Old Way Was Better
Message-ID:  <xvoexvhxii.exv@mail.comcast.net>
In-Reply-To: <a06001a0bbb81d25b67db@[10.0.1.2]> (Brad Knowles's message of "Mon, 8 Sep 2003 08:41:42 %2B0200")
References:  <3F5B4AA9.1000003@lpthe.jussieu.fr> <4k7k4kjbpz.k4k@mail.comcast.net> <a06001a0bbb81d25b67db@[10.0.1.2]>

next in thread | previous in thread | raw e-mail | index | archive | help
Brad Knowles <brad.knowles@skynet.be> writes:

> At 6:44 PM -0700 2003/09/07, Gary W. Swearingen wrote:
>
>>    #-BETA      -- Name of the RELENG_# branch.
>>                    (Was: #-STABLE.)
>>                    (Non-existent until #.#-STABLE is created.)
>>                    (Example: 4-BETA = RELENG_4)
>
> 	No, not correct.  Problem is that bugs are sometimes caught up
> 	in a -RELEASE, which actually won't run or even install on
> 	certain types of systems.  There's a reason STABLE is called
> 	that -- it's almost always better than the most recent RELEASE
> 	for the same line, since it is basically just that same
> 	RELEASE plus bug fixes.  There are times when this is not true
> 	(mostly when some new feature has been recently MFC'ed, or
> 	when a -RELEASE has been cut for CURRENT), but this is true
> 	far more often than not.

Remember what we're talking about here.  The naming of branches and
releases in general, and especially releases the normal users can use
with as much confidence as possible.  While it's true that untested
FreeBSD beta code is often better than the last tested release, it's
also true that it sometimes so bad that it won't even compile.  The
universal advice is to not use the beta code without good testing.
It's foolish to label such code STABLE.  Many people choose to use the
beta code and think they can test it well enough themselves, but
that's a different issue that has little to do with the naming of the
branches and releases.  If anything, it suggests that the beta code
should be designated as "UNTESTED" or "BETA".

>>    #.#-BETA    -- Name of the RELENG_#_# branch, when beta quality.
>>                    (Uncommon. Example: 5.1-BETA = RELENG_5_1)
>>    #.#-STABLE  -- Name of the RELENG_#_# branch, when stable quality.
>>                    (Common. Example: 4.8-STABLE = RELENG_4_8)
>
> 	Therein likes the problem.  There is no distinction between
> 	"beta" or "stable" quality in the system today, and it would
> 	take a massive change in the entire release engineering
> 	process before you could do that.

Sure there's a distinction.  RELENG_5_1 has been designated "not
STABLE" (alpha) and RELENG_4_8 was called "STABLE" (beta) and
RELENG_4_8_0_RELEASE was announced as tested and ready for wide use
(stable).  It takes no massive change in anything for people to write
"5.1-BETA" and "5.2-STABLE" instead of "5.1-RELEASE" and
"5.2-RELEASE", or "5.1.2-BETA" instead of "5.1-RC1", etc.

> 	Like, basically throw out all history of how work has ever
> 	been done (and the people who've done all that work), and
> 	start over from zero.

Humbug.  I'm only talking about using better names.  There's no change
to what's being done (branching, releasing, or even CVS naming).

> 	Moreover, since there are usually extreme generational changes
> 	between major versions, what is really needed is a split

It's fun to propose changes, isn't it?  Yours make mine look trivial.

> 	You are confusing the CVS tags RELENG_5 and RELENG_5_2 with
> 	the human-visible terms such as 5.2-RC1, 5.2-RC2, etc....

How can you say that I confused them when my version had the tags
labeled "tag"?  Eg:
  Sept 29, 2003: 5.2-STABLE (tags RELENG_5_2_0_RELENG, RELENG_5_2, RELENG_5)

Let me repeat that I wouldn't mind seeing branches and releases
referred to by more-or-less meaningless names like the tag names,
as long as the stuff is well described.  But people seem to require
designations which indicate the nature of the product.  



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xvoexvhxii.exv>