Re: is "stable" "stable"?
In message <[EMAIL PROTECTED]> Chris BeHanna writes: : > Then use a point release with the security patches applied. : : I.e., track RELENG_4_3 instead of RELENG_4. Since 4.3 was released, there have been only 9 commits to the 4.3 branch. That's gotta be insanely stable. :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: is "stable" "stable"?
On Mon, 23 Jul 2001 09:52:49 +0200 (CEST) "A. L. Meyers" <[EMAIL PROTECTED]> wrote: AM> A comparison: AM> Debian GNU/Linux has 3 trees: 1. stable 2. testing 3. unstable RELENG_4_3, RELENG_4, 'Top of Tree' (in CVS terms) security, stable, current(in release name terms) AM> The FreeBSD "stable" appears more comparable a mix of "stable" AM> and "testing". Debian GNU/Linux only release a major "stable" AM> update once yearly, a shorter interval being considered bug AM> churning. Hmm FreeBSD runs a *RELEASE* three times a year, what would be the point of a branch that moves *slower* than releases ? AM> ensure that "stable" means what it says. Do you seriously expect AM> all users to go thru the testing procedures enumerated below? I expect it in commercial environments (Solaris installs get treated this way where I work for example). I don't treat my home systems this way and I accept the risk. AM> Most probably expect such things to be done by developers before AM> new and/or improved code is incorporated into "stable". This an unreasonable expectation, commercial vendors cannot achieve this (note they *never* give access to any development stream, employ testers and still ship bugs) why should open source projects be able to do so much better. (actually they do the -stable tree is at least as good as the 'track the patches' game on any commercial OS). -- Directable Mirrors - A Better Way To Focus The Sun http://www.best.com/~sohara To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: is "stable" "stable"?
On Mon, 23 Jul 2001, A. L. Meyers wrote: > Guess what - I *did* carefully read the handbook before cvsupping > stable. Ahh, I see. So... You read, http://www.freebsd.org/doc/en_US.ISO8859-1/books/ \ handbook/current-stable.html Under, "20.2.2.3 Using FreeBSD-STABLE" Which states, "Join the FreeBSD-stable mailing list <[EMAIL PROTECTED]>. This will keep you informed of build-dependencies that may appear in FreeBSD-STABLE or any other issues requiring special attention." Upon reading this, you tracked -stable for awhile and after seeing there weren't known problems with your intended architecture (possibly utilizing list archives as well) proceeded with your install. Correct? > Now I am told that sysadmins should extensively test stable to > make sure it is stable. My conclusions: My conclusion (sorry, no offense!): "More people should learn how to read past a 3rd-grade level." Later, -Mike -- Log analysis mailing list: http://www.adept.org/mailinglists.html#logwatchers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: is "stable" "stable"?
On Mon, 23 Jul 2001, Steve Lumos wrote: > "the stable branch is effectively a bug-fix stream relative to the > previous release" True. > "[-RELEASE is] really just a ``snapshot'' from the -STABLE branch that > we put on CDROM," Well, it is really a snapshot, that's true again. Maybe it would be helpful to indicate that some amount of effort goes into ensuring the 'snapshot' is release-quality (I.e. code freezes, etc.). > sure sound like where I want to be. Actually, the user you describe as just 'ending up' places vs. actually RTFMing and making informed decissions sounds like a newbie. With that in mind, I'd suggest reading: http://www.freebsd.org/projects/newbies.html Specifically, "If you haven't installed yet, look for the *latest mainstream release*." "Latest mainstream release" being a link to (at present) 4.3R. No one suggested that people so easily confused by development cycles actually try to install non-release releases. > I claim that there is a certain amount of stability being advertised > there. Correct. It's advertised, and is present. -STABLE is more 'stable' than -CURRENT. > "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," Correct. > "Changes to this branch have not been widely tested and should not > be depended on to work." Hmm. Speak for yourself, and your apparent lack of clue. Personally, I have many working -STABLE boxes. > I'm not whining about -STABLE, but then again I didn't lose. However, > I think the current attitude toward people who end up losing after > basically being led to -STABLE by the documentation is bad. It might > be a good idea to add "NOTE: Since this documentation may be out of > date with respect to -STABLE, you should never consider tracking it > until you have read freebsd-stable for a couple of weeks." I don't have attitude toward people that 'lose'. I don't think anyone does. That's why you see hundreds of messages in list archives from individuals offering suggestions and help to those that have 'lost'. I do, however, have mass attitude toward individuals who fail then attempt to blame the failure on something other than themselves. It is suggested that users track relevant mailing lists for whichever branch they choose. In short, it's suggested users actually attempt to understand what they use. It may be worth noting that the official Handbook install procedure links to installation floppies for the current -RELEASE. Again, noone suggests users incapable of RTFMing run non-release releases. I can't stress this enough. Personally, I think the current naming convention makes a lot of sense. I also think that, no matter what names you chose for the branches, someone will dissent. I'm all for removing actual inconsistencies in the documentation. However, if this is really just an attempt to have things worded 'your way', I could argue I want it 'my way' (anyone could). Many of the places you cite above say exactly what they should say. I'm glad to know some work has been done to clarify past points of confusion (kudos to the docs team), I just hope time isn't wasted rewriting documentation for the sake of pleasing everyone (vs. saying what needs to be said)... As we all know, that's an endless battle. Later, -Mike -- Log analysis mailing list: http://www.adept.org/mailinglists.html#logwatchers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: is "stable" "stable"?
On Mon, 23 Jul 2001, A. L. Meyers wrote: > It seems to me that it would be in the very best interest of > FreeBSD to apply whatever quality controls are appropriate to > ensure that "stable" means what it says. You're checking out the head of a development tree. It will never be stable in your sense. As mentioned before it might theoretically be best to rename "stable" but it needs a volunteer (you?) to do the work to fix all the breakage which will result. > Do you seriously expect > all users to go thru the testing procedures enumerated below? Then use a point release with the security patches applied. > Most probably expect such things to be done by developers before > new and/or improved code is incorporated into "stable". Like I said, the testing matrix of the x86 platforms are way too damn fucking big. Do you know how many different flavors of intel eepro100 chips alone are out there? Do you think that any of the fxp developers have a full matrix of all of them? Do you even think that the people who are -current have all of them? Multiply that just by the number of x86 motherboards out there and you will get some idea of what kind of testing matrix we're talking about. Of course, are you volunteering to do QA on code before it goes into stable? If you've got the hardware and the manpower then maybe we can do something about it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: is "stable" "stable"?
On Mon, 23 Jul 2001, Max Khon wrote: > hi, there! > > On Mon, 23 Jul 2001, Steve Lumos wrote: > > > I'm not whining about -STABLE, but then again I didn't lose. However, > > I think the current attitude toward people who end up losing after > > basically being led to -STABLE by the documentation is bad. It might > > be a good idea to add "NOTE: Since this documentation may be out of > > date with respect to -STABLE, you should never consider tracking it > > until you have read freebsd-stable for a couple of weeks." > > this happened because RELENG_4_3 is quite new idea (it is actually the > first -RELEASE branch) and seems that handbook is really out of sync with > real world > > /fjoe > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > Hello again! Guess what - I *did* carefully read the handbook before cvsupping stable. I *never* expected stable to be perfect but I did expect it to be "stable". All the docs I saw presented moving from RELEASE to STABLE as the normal course of action. No doc I remember mentioned a third tree. Maybe I misunderstood but my understanding was that a release is something like a snapshot from the stable branch. Well as we have an SMP server I was (sorry, but it's true) shocked to see big problems on production SMP machines due to some problems with stable soon after I subscribed. My mild problem was only with one executable pod2man, part of perl. So I just got nibbled. Now I am told that sysadmins should extensively test stable to make sure it is stable. My conclusions: 1. "Stable" should really be stable or be called something else. 2. The new "release" tree is apparently the real "stable" tree. 3. The handbook does not yet fully and accurately reflect the current situation and inform users sufficiently to enable them to decide rationally. All this is meant in completely positive ways. I like FreeBSD. Cheers! Lucien To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: is "stable" "stable"?
hi, there! On Mon, 23 Jul 2001, Steve Lumos wrote: > I'm not whining about -STABLE, but then again I didn't lose. However, > I think the current attitude toward people who end up losing after > basically being led to -STABLE by the documentation is bad. It might > be a good idea to add "NOTE: Since this documentation may be out of > date with respect to -STABLE, you should never consider tracking it > until you have read freebsd-stable for a couple of weeks." this happened because RELENG_4_3 is quite new idea (it is actually the first -RELEASE branch) and seems that handbook is really out of sync with real world /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: is "stable" "stable"?
Mike Hoskins <[EMAIL PROTECTED]>: >On Sun, 22 Jul 2001, Steve Lumos wrote: > >> It is very easy for a reasonable person to read (or more likely skim >> [tell me you don't do it]) the description of -STABLE in the handbook >> and conclude that it means what it sounds like, and then feel >> bamboozled when they get here. > >I've been known to skim a doc or two, but something this critical isn't >the place to skim. If the individual in question wishes to deploy a >highly stable environment, one would think that individual would take >great care - including following the suggestions made earlier by others >(regression testing, staging, etc.). > >If you're not willing to actually read docs, regression test, stage, and >do 'work' in general... Well, one could argue you get the amount of >stability you deserve. > >Later, >-Mike OK, but I don't really think that's a reason not to make the documentation clear. There are plenty of people who aren't mission critical, but just interested who end up losing when they don't have to. If you guys want to take it upon yourself to teach them a lesson, I suppose that's fine, but I was assuming that wasn't the case. Of course I butted in because I read the documentation and didn't get out of it any indication that -STABLE wasn't where I wanted to be. Certainly, the phrases: "the stable branch is effectively a bug-fix stream relative to the previous release", and "[-RELEASE is] really just a ``snapshot'' from the -STABLE branch that we put on CDROM," sure sound like where I want to be. I claim that there is a certain amount of stability being advertised there. If -STABLE was ALWAYS meant to be what you guys say, then I don't think whoever wrote that section of the handbook knew it. I notice that the changes have already appeared in the handbook at freebsd.org. Although it is much better, it keeps a lot of the same language and just adds qualification. For example, why do you want: "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," instead of "Changes to this branch have not been widely tested and should not be depended on to work." You should also change the text in -CURRENT. The phrase "if you are new to FreeBSD, you are most likely going to want to think twice about running it" should be moved from -CURRENT to -STABLE but even stronger, like "unless you *really know what you are doing*, think twice before tracking -STABLE". Then replace that paragraph in -CURRENT with something like: "As you are reading this, keep in mind that FreeBSD-CURRENT is the ``bleeding edge'' of FreeBSD development and is not intended for users". And while you're making changes, statements like: "The current ports tree officially supports only FreeBSD-current and FreeBSD-stable." on http://freebsd.org/ports/ certainly don't help. That page even goes out of its way to push -STABLE: "Note that it will only change just enough files to enable ports/packages to be used; for a full upgrade to -STABLE, please refer to the synchronizing your source tree section of the handbook." Access to bugfixed ports is the main reason why I ever considered tracking -STABLE. I'm not whining about -STABLE, but then again I didn't lose. However, I think the current attitude toward people who end up losing after basically being led to -STABLE by the documentation is bad. It might be a good idea to add "NOTE: Since this documentation may be out of date with respect to -STABLE, you should never consider tracking it until you have read freebsd-stable for a couple of weeks." Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: is "stable" "stable"?
On Mon, 23 Jul 2001, A. L. Meyers wrote: > do you suggest that if someone wants "stable-stable" not just > "stable" he should cvsup RELENG_4_3 instead of RELENG_4? I suggest you spend half the time reading documentation and trying to actually understand the FreeBSD build hierarchy you do posting messages here about what 'stable' is and/or what -STABLE should be called. (No offense, but this thread is a dead horse. If you'd take a few seconds to search past list archives, you'd already know that.) Later, -Mike -- Log analysis mailing list: http://www.adept.org/mailinglists.html#logwatchers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: is "stable" "stable"?
Very well said. This should be added to the handbook. :) From: Lamont Granquist <[EMAIL PROTECTED]> Subject: Re: is "stable" "stable"? Date: Sat, 21 Jul 2001 11:27:01 -0700 (PDT) > > On Sat, 21 Jul 2001, A. L. Meyers wrote: > > Having followed the postings here for a few weeks it seems, at > > least occasionally, that "stable" appears to be a bit less than > > "stable". > > You are doing a CVS checkout of a source tree that is getting updates > on a daily basis. If you have ever done this in a development environment > before, you should know that absolute 100% stability in any such an > environment is never, ever going to happen. > > If you want the latest -stable sources which *are* stable, then you > really need to checkout sources on a fresh machine, build your > distribution and spend a few days regression testing the features of the > OS which are important to you. You should then roll out the build to > your staging platform and give it at least a week or two. Following that > you should put it in the load balancing rotation on your production site, > and then gradually phase it in as you gain more confidence. > > Which, of course, you should be doing anyway. > > If you want better stability, then checkout the actual 4.x releases with > the security fixes. Those have actually been frozen and then bugfixed for > stability. They should be better. > > Why is this so difficult for people to understand? *ANY* time you are > checking out the head of a development branch (even one where developers > are supposedly being "more careful") then you should expect to > occasionally see problems. People will break the build. People will have > insufficiently tested their code and subsystems will break. I guarantee > you that none of the FBSD developers have a sufficient testing matrix to > *ensure* that the changes which are checked into the top of the tree will > run on every platform out there (consider for a moment just how big the > x86 testing matrix is). I'm pretty damned impressed that -stable works as > well as it does (kudos for the developers). > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
