Date: Mon, 23 Jul 2001 14:25:15 -0600 From: "Mike Porter" <mike.porter@xrxgsn.com> To: "Mike Hoskins" <mike@adept.org>, "Steve Lumos" <slumos@nevada.edu> Cc: <freebsd-stable@FreeBSD.ORG> Subject: Re: is "stable" "stable"? Message-ID: <026901c113b5$96c53740$0300a8c0@laptop>
next in thread | raw e-mail | index | archive | help
-----Original Message----- From: Steve Lumos <slumos@nevada.edu> To: Mike Hoskins <mike@adept.org> Cc: freebsd-stable@FreeBSD.ORG <freebsd-stable@FreeBSD.ORG> Date: Monday, July 23, 2001 12:24 PM Subject: Re: is "stable" "stable"? >Mike Hoskins <mike@adept.org>: >>On Mon, 23 Jul 2001, Steve Lumos wrote: >>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*." > >This is a perfect example of how the documentation is going wrong. If >you have installed FreeBSD, then that ain't you. That's one reason >why I suggested changing "if you are new to FreeBSD, you are most >likely going to want to think twice about running [-CURRENT]." There >are a lot more people who ought to think twice about running -CURRENT >then just those who are "new to FreeBSD". > And as a general rule, unless you are new to freeBSD, you are going to know what you are getting into trying to run -CURRENT. And if you continue reading into section 20.2.1.1, you will find "but whether or not FreeBSD-CURRENT sources bring disaster or greatly desired functionality can literally be a matter of which part of any given 24 hour period you grabbed them in!" In 20.2.1.3 you read that freeBSD-CURRENT is /not/(emphasis in original)"In any way ``officially supported'' by us". Translation: newbies to freeBSD need not even delve into the subsections below about current. Those not new to freeBSD should read on, and then decide if it is "right" for you. The idea isn't necessarily to turn people off of running -CURRENT, but to let them know that the going may be rocky. In fact, if more people ran -CURRENT, it would have the effect of increasing the testing matrix....assuming that people who have problems actually report them, of course, but that's a whole other can of worms. If I had the time to devote to it, I would happily run -CURRENT, but there IS a significant time investment. >>> "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. > >Well, I might not be the most clueful person in the world, but I can >usually manage to avoid having ad hominem and hasty generalization >fallacies in consecutive sentences. Do you dislike that sentence >because you claim that -STABLE has been widely tested, or that it >should be depended on to work, or both? > I personally have had zero problems with -STABLE. As previously mentioned on this thread, becuase of the size of the testing matrix, there really is no humanly possible way to test every possible configuration: Not only do manufacturer's sometimes change the design of products without telling anyone (Intel's eepro100 is a good example of that--and worse, the changes actually broke stuff, so fxp code that worked with one version, suddenly DIDN'T work witht he new version--a new version that if I understand correctly had the SAME MARKINGS on the chip. How is a volunteer devolper supposed to know that?), and not only would you then again have to multiply this by the number of motherboard models out there in the x86 world (and don't forget all the old 386 and 486 boards!) but a lot of boards, especially older boards (some of the early PCI boards, notably, especially the 486-based ones...)have bugs related to specific slots...so not only do you have to test every known motherboard with every known version of the eepro100, but you also have to test it *in every slot* to be assured that there will be no problems. And don't forget all the customized BIOS tweaks... -Stable has been tested to the best of the abilities of those doing the testing. If you have a problem with that, then as has been suggested, why don't you volunteer to help? FreeBSD is, after all, a volunteer effort, and the way it gets improved is by people noticing a problem, and offering to help with the solution. Simply pointing out the problem isn't going to do you or anyone else any good. What is needed is SOLUTIONS. Your proposed modfications to the handbook really aren't what most people have experienced. And again, if you look online at the current version of the handbook:in 20.2.2.1:"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." There is nothing untrue about that statement. The people testing in -CURRENT have tested it, and resolved any problems. That YOUR SPECIFIC HARDWARE may not have been tested is certainly not their fault. If you are that concerened that your specific configuration gets tested, why don't you build an exact clone of your machine and send it to one of the testers, so they can test your machine. Dont forget to put everything in the same slot, use the same BIOS version, and include any dual-boot, etc, configuration. Even then, becuase there are differences between -CURRENT and -STABLE, there is a chance that something may break, of course, as sometimes the breakage is in the interactions between stuff.... COntinuing in the handbook, we come to section 20.2.2.2:"If you are interested in tracking the FreeBSD development process, and you want early access to the features that will appear in the next ``point'' release of FreeBSD then you should consider following FreeBSD-STABLE." "development process"..."/consider/ tracking" (emphasis mine). Later on in 20.2.2.2:"However, you do not need to track FreeBSD-STABLE to do this, as every security advisory for FreeBSD explains how to fix the problem for the releases it affects." "You DO NOT need..." seems pretty clear to me! Still in 20.2.2.2:"Although we endeavor to ensure that the FreeBSD-STABLE branch compiles and runs at all times, this cannot be guaranteed. In addition, while code is developed in FreeBSD-CURRENT before including it in FreeBSD-STABLE, more people run FreeBSD-STABLE than FreeBSD-CURRENT, so it is inevitable that bugs and corner cases will sometimes be found in FreeBSD-STABLE that were not apparent in FreeBSD-CURRENT." So far, nothing we haven't heard before. Perhaps a clarification of the first paragraph of 20.2.2. And again: "For these reasons, we do not recommend that you blindly track FreeBSD-STABLE, and it is particularly important that you do not update any production servers to FreeBSD-STABLE without first thoroughly testing the code in your development environment." Sounds like stuff a lot of people have said in this thread and other, previous threads along this line. Or was it just my imaginiation? <(}; And finally, the last paragraph of 20.2.2.2: "If you do not have the resources to do this then we recommend that you run the most recent release of FreeBSD, and use the binary update mechanism to move from release to release." Any questions? I would point out that ALL of that comes before any discussion of HOW to get -STABLE, and clearly you managed to read THAT section well enough. Is it really too much to ask that people RTFM?? (no offense intended towards the people who wrote THIS manual <(}; ) The only thing that I would suggest adding (for anyone who has made it this far), is to copy the line from 20.2.1 about subscribing to the -current mailing list not just being a good idea, but being essential, and lay it into the section about subscribing to -stable. I would agree that it is somewhat *less* essential than with current, but it is still pretty darn important. I seem to recall that the older version of the handbook said something along those lines, and also along the lines of waiting a week or so after subscribing to -stable before actually pulling and compiling sources. But that may have been in Greg's book, which I also have and refer to frequently (thanks, Greg!). well, 'nuff said on this topic, I think I've exhausted my month's -stable allotment... <(}: mike >>From what other people have said, it seems to be the case that a) >-STABLE used to be exactly what the handbook (until the most recent >update) says it is, and b) it's not anymore, but RELENG_<major>_ ><minor> is instead. I would be interested to hear somebody >authoritative correct that, but otherwise it means the handbook needs >to be fixed. No big deal, seems to be happening already, everybody be >happy. > >Steve > >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?026901c113b5$96c53740$0300a8c0>