Hello people!
Before you all bang around on my head :-) hear me out on this one. It's

actually possible that someone has already made this suggestion and I

haven't found that thread yet. If so, please point me in the right

direction and I'll read up on it, before writing in this thread again.
In computer science and mathematics, we sometimes use terms from the

"normal" language but use them just a little differently than people

outside of our circle would. Sometimes that is unavoidable because our

language is just doesn't have enough words to express our thoughts - and

to express them exactly. This is usually not much of a problem. However,

sometimes we have to communicate with others, who may use our products and

ideas but don't embrace our language.
As the subject of this thread already suggests, I am referring to the

names of the developement branches, which I (even as a computer scientist)

consider a little "strange".
If someone sees the result of RELENG_6 is called STABLE, he or she will

problably think, this is the line where bug fixes are added, security

problems fixed and the whole thing is meant for production systems. While

the first two things may be true, I would not suggest RELENG_6 for

production systems. Normally the -STABLE line works fine. But I *have*

times in the past where a driver was changes and suddenly the system

*didn't* work after a reboot or showed strange behaviour.
What you could (and should?) use for a production system is RELENG_6_2. I

am using that, as you can see in the header. :-) Although the handbook

titles RELENG_6 as "staying stable...", people are warned not to use it on

production systems (which seems strange for something called "stable")

while RELENG_6_x isn't even mentioned.
What I propose is this:
When we have FreeBSD 7.0-RELEASE, we change these things a little.
- What is -CURRENT now stays -CURRENT (then probably 8-CURRENT).

- RELENG_7 is also called -CURRENT (7.x-CURRENT)

- RELENG_7_x could be called 7.x-RELEASE-px (see ...
[ message continues ]

Christian, good day.
But let us look at the issue from the user's side: where can he get

RELENG_6?  Only cvsup, CTM and monthly snapshots come into my mind.

Regular CDs/ISOs will deliver RELENG_6_x.  Users that are trying

to use snapshots should realize that they're doing it at their own

risk, but maybe documentation and FTP directory messages should

tell them that shapshots can broke their installations.  Seems like

CTM users are the educated persons, so they won't need any

clarifications.  Examples of the CVSup supfiles are the good

candidates for the short messages clarifying the nature of the

-STABLE and referring to the relevant Handbook sections for more

explanations.

--

Eygene

_______________________________________________

freebsd-current@freebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-current

To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

Hi,
The handbook explicitly explains it:

---------------------------------------------------------------------------

23.2.2.1 What Is FreeBSD-STABLE?
FreeBSD-STABLE is our development branch from which major releases are

made. Changes go into this branch at a different pace, and with the

general assumption that they have first gone into FreeBSD-CURRENT for

testing. This is still a development branch, however, and this means that

at any given time, the sources for FreeBSD-STABLE may or may not be

suitable for any particular purpose. It is simply another engineering

development track, not a resource for end-users.
I would think that someone who uses these tools may look into the

handbook. I would guess that most people get the idea of updating via

sources from the handbook so this part is hard to miss.
And it is headlined "Chapter 23 The Cutting Edge", btw.
However, I tried to find information about the RELENG tags useful for

production systems in the handbook.
The only place I find them mentioned is in the appendix: "A.7.1 Branch

Tags".
"14.14 FreeBSD Security Advisories" don't mention RELENG tags.
So the use of RELENG tags is not that obvious for a newcomer I think.

Maybe we should add a comment in the Chapters 23 (Cutting Edge) and 14.14

(Security advisories).
To come up with good names isn't that easy. Look at Debian: stable,

unstable, testing. It's different but not better I think.
Fortunatelly the most FreeBSD releases deserve the attribute stable:-) So

when I maintained FreeBSD servers I rarely saw a reason to update to "the

kernel of the week". Besides of some security patches I just did it once

in a while to a new release, just to keep servers in sync.
Of course carefully. Every change of a running system (not only if it's

FreeBSD;-) is a risk.
BTW: Even my -CURRENT desktop is more stable than a Fedora release I had

to endure at work for a while:-)
Regards

Peter

_______________________________________________

freebsd-current@...
[ message continues ]

There was a thread on this a few years back when we only had the

-CURRENT and -STABLE branches.  The problem at that time was that when

code was being back ported from -CURRENT to -STABLE it would break

production machines that had been updated to the latest -STABLE code.
The solution was to create the -STABLE security branches where only
The handbook needs a new section added to:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable...
which details what the -STABLE security branches (RELENG_x_y) are to

23.2.2.3 What are the FreeBSD-STABLE security branches?
If you are interested in tracking the security of the current STABLE

-RELEASE, then you should consider following the FreeBSD-STABLE

security branch.
The FreeBSD -STABLE security branches tracks only security and minor

fixes relating to the currently supported STABLE -RELEASES. No major

changes are made to these branches.
Although we endeavor to ensure that the FreeBSD-STABLE security branch

compiles and runs at all times, this cannot be guaranteed. <Re-write?>
We do not recommend that you blindly update any production servers to

FreeBSD-STABLE security branch without first thoroughly testing the

code in your development environment.
To use the -STABLE security branch you need to check out the FreeBSD

sources using the RELENG_x_y tag.
Scot

_______________________________________________

freebsd-current@freebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-current

To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

Hello,
This was discussed many times in -stable mail list (and probably on few

others?)

Anyway STABLE means stable API, so programs compiled on 6.2-RELEASE

should work on 6.2-STABLE
You can look for "ARRRRGH!  Guys, who's breaking -STABLE's GMIRROR

code?!" - very long thread,

but normally when something broke in -stable this thread start and start

again.
P.S. for me STABLE is very stable, and current CURRENT is even more

stable (at least on new hardware),

and I have both in production.
-- 
Best Wishes,

Stefan Lambrev

ICQ# 24134177
_______________________________________________

freebsd-current@freebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-current

To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

YMMV.  I run both CURRENT and STABLE on production systems.
DES

--=20

Dag-Erling Sm=C3=B8rgrav - des@des.no

_______________________________________________

freebsd-current@freebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-current

To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

And we'll find many other people on this newsgroup who do the same, but

not everyone's a kernel hacker, or even a decent programmer, so it's

kind of insignificant.
This will probably degenerate into a bikeshed so I'll add just one

suggestion: rename "-STABLE" to "-ABISTABLE" or "-STABLEABI" and carry

on as usual. :)

On Wed, Oct 10, 2007 at 05:29:12PM +0200 I heard the voice of
I'm not a kernel hacker, and I don't remember the last time I ran a

production system on a release longer than it took to do a buildworld,

going back to 2.1.x.  My workstation runs -CURRENT, though I rarely

run -CURRENT on other production systems (rarely != never, but it is

rare).
--

Matthew Fuller     (MF4839)   |  fullermd@over-yonder.net

Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

           On the Internet, nobody can hear you scream.

_______________________________________________

freebsd-current@freebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-current

To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

Unfortunately (for this developer-centric practice), the trend in large

and/or important production environments is - as seen in Linux (and

Solaris) - to severely limit major OS upgrades. Of course the existing

possibility to do is excellent, but more and more end-users, especially

big ones, are going with big Linux distributions that basically stay

frozen (except for security upgrades) for years. And this idea gets a +1

from me - productions releases that are expected to run for years should

be able to "just work" without upgrading to the "kernel of the week". To

do this, a stable anchor-point is required and that's what -RELEASEes

should be for. I think the fact that not all our -RELEASES are created

equal (some are "extended support" releases) should be more advertised

and explained.

Which is higly interesting and important and has basically nothing to do with the original mail / question by the original author ;-)
Back to topic?

The problem is, that STABLE in FreeBSD-speak is meant as API Stable, not stable in regards to a broken driver or in regards to a branch where the source is frozen.

However, I do agree with the original author that it leads to confusion, because API stabilitiy is not the first thing that pops into your mind when you read FreeBSD 6-STABLE ;-)
I tend to believe that a renaming won't happen, though. AFAIK the naming convention in FreeBSD haven't changed since... well... forever? ;)

It may became something like a holy cow :)
My thoughts.
Cheers,

Marian
PS.: I managed to run CURRENT from yesterday on a IBM HS21 Blade with this bloody mpt(4) and bce(4) chipsets. It works! Thumbs Up! The bce(4) was panicing in earlier CURRENTs I tried :) 
_______________________________________________

freebsd-current@freebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-current

To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"