Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Michael Abbott wrote: Roland Smith wrote: Martin Nilsson wrote: Hans Lambermont wrote: .. or just stop calling it STABLE and call it RELENG_6 instead That's a good idea, IMHO. When I started with FreeBSD I found the difference between the branch names and cvs tags confusing. Let me second that. I hadn't realised that STABLE==RELENG_n (where n is the current version number) until very recently, and I've seen the STABLE isn't stable thing crop up over and over again over the last few years, both on mailing lists and IRC. Actually, FreeBSD has three types of branches: - current a.k.a. HEAD - X-stable a.k.a. RELENG_X - X.Y security branch a.k.a. RELENG_X_Y I think it would be better to rename the 2nd one RELENG (instead of STABLE), because that's exactly what it is: the release-engineering branch from which the releases are derived. The term STABLE would be much better suitable for the 3rd type of branches which are currently called security branches. Thus we would have: - current - releng - stable Then the names match exactly what the branches are: current is the current head of experimental development, releng is the release engineering branch, and stable is the stable branch for people who want to track only security fixes and the most critical stuff. Such appropriate naming would certainly prevent a lot of confusion. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. The last good thing written in C was Franz Schubert's Symphony number 9. -- Erwin Dieterich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Mon, 18 Sep 2006, Oliver Fromme wrote: [...] Then the names match exactly what the branches are: current is the current head of experimental development, releng is the release engineering branch, and stable is the stable branch for people who want to track only security fixes and the most critical stuff. Which is pretty well what OpenLDAP does; over there, HEAD is bleeding edge, RELEASE is the latest version, and STABLE is, well, stable as understood by most humans... See http://www.openldap.org/software/download/ -- Dave ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Oliver Fromme wrote: Michael Abbott wrote: Roland Smith wrote: Martin Nilsson wrote: Hans Lambermont wrote: .. or just stop calling it STABLE and call it RELENG_6 instead That's a good idea, IMHO. When I started with FreeBSD I found the difference between the branch names and cvs tags confusing. Let me second that. I hadn't realised that STABLE==RELENG_n (where n is the current version number) until very recently, and I've seen the STABLE isn't stable thing crop up over and over again over the last few years, both on mailing lists and IRC. Actually, FreeBSD has three types of branches: - current a.k.a. HEAD - X-stable a.k.a. RELENG_X - X.Y security branch a.k.a. RELENG_X_Y I think it would be better to rename the 2nd one RELENG (instead of STABLE), because that's exactly what it is: the release-engineering branch from which the releases are derived. The term STABLE would be much better suitable for the 3rd type of branches which are currently called security branches. Thus we would have: - current - releng - stable Then the names match exactly what the branches are: current is the current head of experimental development, releng is the release engineering branch, and stable is the stable branch for people who want to track only security fixes and the most critical stuff. Such appropriate naming would certainly prevent a lot of confusion. Best regards Oliver I agree! My $.02 Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: arrrrgh! Guys, who's breaking -STABLE's gmirror code?!
On Sun, Sep 17, 2006 at 11:39:55AM +0200, Daniel Gerzo wrote: Your Windows must be really badly broken, because my Windows XP spontaneously rebooted only once in those many years I have been using it. In my opinion, XP is pretty decent system. Your standards are pretty low. I've got freebsd/solaris systems with uptimes nearing 6 years. I've *NEVER* had a spontaneous reboot from either operation system. If I did, I'd spent hours in the back hammering down exactly why. I don't run either Linux or Windows for exactly the reasons you mention, except as gaming computers that I wipe/rebuild on a regular basis. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Hans Lambermont wrote: Julian H. Stacey wrote: Stable is a misnomer that harms FreeBSD somewhat. Why not rename 'stable' into 'stable-api' ? Nice, an improvement on what we have :-) If enough agree, the name of this mail list could be changed for a start. -- Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz. Don't buy it ! Get it free ! http://berklix.org/free-software ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Fri, Sep 15, 2006 at 03:41:04PM -0300, Marc G. Fournier wrote: But, I'm just curious here ... for all of the talk going around about this whole issue, how many ppl have truly ever been bitten by an unstable -STABLE? And for those that have, how long did it take to get help from a developer to get it fixed? I run -STABLE on a number of production machines. I have twice been bitten by an unstable -STABLE -- but bitten in a very small way. When we build a new -STABLE (on average perhaps once per month), we build it on a test machine, so that we can be sure that it actually works. Once it is tested and we know it works, then we can roll it out to the production machines without undue concern. I note that we follow the same process with out Linux machines, our Irix machines, and our Windows machines. Blindly rolling out updates or patches to critical production machines is unwise and dangerous (at least IMO). I will add that I have never even needed to contact a maintainer. When there has been a problem, I checked the lists. In one case the fix was already committed, in the other there was already an I'm working on it message and a fix was commited in less than 24 hours. In the interim, my test machine had a problem -- but that's what a test machine is for. In the case that started this thread, it seems to be that the developer fixed his mistake fairly quickly, which is what one would expect ... it shouldn't be so much that he *broke* -STABLE (shit happens, do you want your money back?), but it should be 'was he around to reverse his mistake in a reasonable amount of time?' ... ? Exactly. -- greg byshenk - [EMAIL PROTECTED] - Leiden, NL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, 16 Sep 2006, Julian H. Stacey wrote: Hans Lambermont wrote: Julian H. Stacey wrote: Stable is a misnomer that harms FreeBSD somewhat. Why not rename 'stable' into 'stable-api' ? Nice, an improvement on what we have :-) If enough agree, the name of this mail list could be changed for a start. Sure, but what colour the new bikeshed? Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Ian Smith wrote: On Sat, 16 Sep 2006, Julian H. Stacey wrote: Hans Lambermont wrote: Julian H. Stacey wrote: Stable is a misnomer that harms FreeBSD somewhat. Why not rename 'stable' into 'stable-api' ? Nice, an improvement on what we have :-) If enough agree, the name of this mail list could be changed for a start. Sure, but what colour the new bikeshed? Trite.Stable != stable. Let Core choose any non misnomer. -- Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz. Don't buy it ! Get it free ! http://berklix.org/free-software ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Fri, 2006-09-15 at 02:09 +0200, Karol Kwiatkowski wrote: On 15/09/2006 01:37, Benjamin Lutz wrote: On Friday 15 September 2006 01:15, Kris Kennaway wrote: Anyone who is confused but doesn't attempt to enlighten themselves by reading the provided documentation deserves to stay confused :) What if they're unaware of their own confusion? I guess they get what they deserves ;) Is there a be better source of enlightenment than a handbook? To quote[1]: --% 21.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. --% Perhaps the flow of FAQs and confusion resulting from the misnomer might be stemmed somewhat if something like the following were appended to that: Note that -STABLE refers to the stability of the FreeBSD API, not to the run-time stability of the branch. The FreeBSD API (normally?) only changes across major version releases. Someone with a more intimate understanding of how it all works could probably write a better version of that. I suspect that the confusion for new users isn't helped by the following statement from the 'version-guide' article: 1.3 STABLE versus CURRENT During the lifetime of each major release, an individual branch may also be termed STABLE. This indicates that the FreeBSD Project believes that the branch is of sufficiently proven quality to be used by a wide range of users. Branches that need further testing before being widely adopted are named CURRENT. The crux of the confusion is exemplified here by the terms wide range of users and widely adopted used in reference to the suggested target audiences for STABLE and CURRENT, respectively. While the explanations themselves are not specifically inaccurate, they are easily misinterpreted or, rather, difficult to interpret correctly, for a new user trying to understand it all. It simply reflects the confusion caused by the use of the STABLE tag. All-in-all, I think Marc G. Fournier had the best suggestion: Or rename it what it is: 6.x-BETA Where x == the next -RELEASE ... Which has at least the following benefits: 1. highlights that the software is BETA (and thus in need of testing - in both senses) 2. shows that the software is version n+1 (n == existing -RELEASE) 3. avoids the confusion of the -STABLE tag (both for new, and - dare I say - existing, users) Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: arrrrgh! Guys, who's breaking -STABLE's gmirror code?!
On Sep 15, 2006, at 24:34, hackmiester (Hunter Fuller) wrote: Hahahahaha... That's ironic... That wasn't meant to be ironic. Years of experience and observations of development lead to this conclusion. RIght. All i can say, though, is that someone that doesn't know any better would probably not think Oh! That means that upgrades are possible between releases, and not that my system will actually run, or anything! It just seems it'd be quite a cause of confusion. So, actually Microsoft may be correctly claiming that WindowsXP is more stable than Linux. That it spontaneously reboots as soon as I bore it isn't related at all... -- Alban Hertroys This person has performed an illegal operation, and will be shot down. !DSPAM:74,450a59b47241130310126! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Jamie Bowden schrieb: On 9/9/06, Mark Andrews [EMAIL PROTECTED] wrote: Yeah, -STABLE is what you should run if you want stable code, right? No. STABLE means STABLE API. If you want stable code you run releases. Between releases stable can become unstable. Think of stable as permanent BETA code. Changes have passed the first level of testing in current which is permanent ALPHA code. No, this is what it means now. [...] Why do you say No if you mean Yes, but in former times ...? Björn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
=?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= wrote: Jamie Bowden schrieb: On 9/9/06, Mark Andrews [EMAIL PROTECTED] wrote: Yeah, -STABLE is what you should run if you want stable code, right? No. STABLE means STABLE API. If you want stable code you run releases. Between releases stable can become unstable. Think of stable as permanent BETA code. Changes have passed the first level of testing in current which is permanent ALPHA code. No, this is what it means now. [...] Why do you say No if you mean Yes, but in former times ...? Stable is a misnomer that harms FreeBSD somewhat. A promoter of FreeBSD I know has long encouraged people to upgrade from release to stable. Some don't won't realise Stable is Not necessarily Stable, may get burnt. Much of the world speaks English only as a 2nd language. They won't benefit from the double trouble of foreign + weird BSD geek speak: Stable isn't Stable ? Yes or No ! It's stable, but it's OK to crash ? - I'll go Linux ! Imagine a boat labelled Stable: It sinks. The designers claim: Tough! We left the Application Interface (routes to bars toilets) stable, but changed other stuff. Hey ! Stable never meant Stable ! It'd be some work to eradicate the misnomer, but the name's perhaps less entrenched than one might guess, eg: ftp ftp.freebsd.org cd /pub/FreeBSD dir lrwxr-xr-x 1 ftpuser ftpusers19 Mar 24 14:58 FreeBSD-stable - branches/4.0-stable cd FreeBSD-stable 550 No such directory. -- Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz. Don't buy it ! Get it free ! http://berklix.org/free-software ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On 15 September 2006, at 11:16, Julian H. Stacey wrote: Stable is a misnomer that harms FreeBSD somewhat. A promoter of FreeBSD I know has long encouraged people to upgrade from release to stable. Some don't won't realise Stable is Not necessarily Stable, may get burnt. Much of the world speaks English only as a 2nd language. They won't benefit from the double trouble of foreign + weird BSD geek speak: Stable isn't Stable ? Yes or No ! It's stable, but it's OK to crash ? - I'll go Linux ! Imagine a boat labelled Stable: It sinks. The designers claim: Tough! We left the Application Interface (routes to bars toilets) stable, but changed other stuff. Hey ! Stable never meant Stable ! This is the perfect explanation. Thank you for putting what I am trying to say in words so well. :-) It'd be some work to eradicate the misnomer, but the name's perhaps less entrenched than one might guess, eg: ftp ftp.freebsd.org cd /pub/FreeBSD dir lrwxr-xr-x 1 ftpuser ftpusers19 Mar 24 14:58 FreeBSD- stable - branches/4.0-stable cd FreeBSD-stable 550 No such directory. -- Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http:// berklix.com Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz. Don't buy it ! Get it free ! http://berklix.org/free-software ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] -- hackmiester (Hunter Fuller) svinx yknow when you go to a party, and everyones hooked up except one guy and one girl svinx and so they look at each other like.. do we have to? svinx intel nvidia must be lookin at each other like that right now Phone Voice: +1 251 589 6348 Fax: Call the voice number and ask. Email General chat: [EMAIL PROTECTED] Large attachments: [EMAIL PROTECTED] SPS-related stuff: [EMAIL PROTECTED] IM AIM: hackmiester1337 Skype: hackmiester31337 YIM: hackm1ester Gtalk: hackmiester MSN: [EMAIL PROTECTED] Xfire: hackmiester ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Julian H. Stacey wrote: Stable is a misnomer that harms FreeBSD somewhat. I agree. A promoter of FreeBSD I know has long encouraged people to upgrade from release to stable. Some don't won't realise Stable is Not necessarily Stable, may get burnt. Much of the world speaks English only as a 2nd language. They won't benefit from the double trouble of foreign + weird BSD geek speak: Stable isn't Stable ? Yes or No ! It's stable, but it's OK to crash ? - I'll go Linux ! Imagine a boat labelled Stable: It sinks. The designers claim: Tough! We left the Application Interface (routes to bars toilets) stable, but changed other stuff. Hey ! Stable never meant Stable ! It'd be some work to eradicate the misnomer, but the name's perhaps less entrenched than one might guess, eg: ftp ftp.freebsd.org cd /pub/FreeBSD dir lrwxr-xr-x 1 ftpuser ftpusers19 Mar 24 14:58 FreeBSD-stable - branches/4.0-stable cd FreeBSD-stable 550 No such directory. Why not rename 'stable' into 'stable-api' ? -- Hans Lambermont ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Fri, 15 Sep 2006, Hans Lambermont wrote: Julian H. Stacey wrote: Stable is a misnomer that harms FreeBSD somewhat. I agree. A promoter of FreeBSD I know has long encouraged people to upgrade from release to stable. Some don't won't realise Stable is Not necessarily Stable, may get burnt. Much of the world speaks English only as a 2nd language. They won't benefit from the double trouble of foreign + weird BSD geek speak: Stable isn't Stable ? Yes or No ! It's stable, but it's OK to crash ? - I'll go Linux ! Imagine a boat labelled Stable: It sinks. The designers claim: Tough! We left the Application Interface (routes to bars toilets) stable, but changed other stuff. Hey ! Stable never meant Stable ! It'd be some work to eradicate the misnomer, but the name's perhaps less entrenched than one might guess, eg: ftp ftp.freebsd.org cd /pub/FreeBSD dir lrwxr-xr-x 1 ftpuser ftpusers19 Mar 24 14:58 FreeBSD-stable - branches/4.0-stable cd FreeBSD-stable 550 No such directory. Why not rename 'stable' into 'stable-api' ? Or rename it what it is: 6.x-BETA Where x == the next -RELEASE ... But, I'm just curious here ... for all of the talk going around about this whole issue, how many ppl have truly ever been bitten by an unstable -STABLE? And for those that have, how long did it take to get help from a developer to get it fixed? In the case that started this thread, it seems to be that the developer fixed his mistake fairly quickly, which is what one would expect ... it shouldn't be so much that he *broke* -STABLE (shit happens, do you want your money back?), but it should be 'was he around to reverse his mistake in a reasonable amount of time?' ... ? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Hans Lambermont wrote: Why not rename 'stable' into 'stable-api' ? .. or just stop calling it STABLE and call it RELENG_6 instead, which is what you are actually fetching from cvs :-) /Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Marc G. Fournier wrote: On Fri, 15 Sep 2006, Hans Lambermont wrote: Julian H. Stacey wrote: Stable is a misnomer that harms FreeBSD somewhat. ... Why not rename 'stable' into 'stable-api' ? Or rename it what it is: 6.x-BETA Where x == the next -RELEASE ... Also fine by me :) I followed this long thread in slight amazement, but the 'what is stable' confusion is very recognizable. I'm open for changing the name. In the case that started this thread, it seems to be that the developer fixed his mistake fairly quickly, which is what one would expect ... it shouldn't be so much that he *broke* -STABLE (shit happens, do you want your money back?), but it should be 'was he around to reverse his mistake in a reasonable amount of time?' ... ? I think the answer is yes (and always has been afaik). regards, Hans Lambermont ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Fri, Sep 15, 2006 at 03:41:04PM -0300, Marc G. Fournier wrote: But, I'm just curious here ... for all of the talk going around about this whole issue, how many ppl have truly ever been bitten by an unstable -STABLE? And for those that have, how long did it take to get help from a developer to get it fixed? After installing from 5.4-RELEASE, I've tracked stable, and I haven't had any real problems. This is a desktop system, not a server, BTW. Maybe it depends on the frequency of updating? I usually update after there has been a security advisory that affects me. Otherwise, if it ain't broken... shouldn't be so much that he *broke* -STABLE (shit happens, do you want your money back?), :-) Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpdquFzheEVn.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Fri, Sep 15, 2006 at 08:46:57PM +0200, Martin Nilsson wrote: Hans Lambermont wrote: Why not rename 'stable' into 'stable-api' ? .. or just stop calling it STABLE and call it RELENG_6 instead, which is what you are actually fetching from cvs :-) That's a good idea, IMHO. When I started with FreeBSD I found the difference between the branch names and cvs tags confusing. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpCYv8bks5SA.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Fri, 15 Sep 2006, Roland Smith wrote: On Fri, Sep 15, 2006 at 08:46:57PM +0200, Martin Nilsson wrote: Hans Lambermont wrote: .. or just stop calling it STABLE and call it RELENG_6 instead That's a good idea, IMHO. When I started with FreeBSD I found the difference between the branch names and cvs tags confusing. Let me second that. I hadn't realised that STABLE==RELENG_n (where n is the current version number) until very recently, and I've seen the STABLE isn't stable thing crop up over and over again over the last few years, both on mailing lists and IRC. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Fri, Sep 15, 2006 at 03:41:04PM -0300, Marc G. Fournier wrote: On Fri, 15 Sep 2006, Hans Lambermont wrote: Julian H. Stacey wrote: Stable is a misnomer that harms FreeBSD somewhat. I agree. A promoter of FreeBSD I know has long encouraged people to upgrade from release to stable. Some don't won't realise Stable is Not necessarily Stable, may get burnt. Much of the world speaks English only as a 2nd language. They won't benefit from the double trouble of foreign + weird BSD geek speak: Stable isn't Stable ? Yes or No ! It's stable, but it's OK to crash ? - I'll go Linux ! Imagine a boat labelled Stable: It sinks. The designers claim: Tough! We left the Application Interface (routes to bars toilets) stable, but changed other stuff. Hey ! Stable never meant Stable ! You've got a good point. Wouldn't be be best to merge the mythical last-bug from x-BETA+ into x and have release-x be the (abs) most stable *for that release*? I have generally run -STABLE ((now/then -RELEASE)); it is to the developers' credit [[all get 5 stars from here!]] that -STABLE has run so flawlessly until now. ---Yeah, I am speaking only for myself; what else :-). Or rename it what it is: 6.x-BETA Where x == the next -RELEASE ... But, I'm just curious here ... for all of the talk going around about this whole issue, how many ppl have truly ever been bitten by an unstable -STABLE? And for those that have, how long did it take to get help from a developer to get it fixed? Indeed. This snafu didn't bite me because I was at 5.4... and right, hat's off and cheers for Pawel Dawidek. Everyone shouldbe as consciencious --it'd be a vastly better world (.) gary In the case that started this thread, it seems to be that the developer fixed his mistake fairly quickly, which is what one would expect ... it shouldn't be so much that he *broke* -STABLE (shit happens, do you want your money back?), but it should be 'was he around to reverse his mistake in a reasonable amount of time?' ... ? -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Marc G. Fournier wrote: Steve O'Hara-Smith wrote: Greg Barniskis [EMAIL PROTECTED] wrote: If you /track/ STABLE by frequently cvsupping it and rebuilding your system, you will very likely encounter a serious problem sooner or later. That's why tracking it is not recommended for production systems. I did exactly that all the way from 2.0 to 4.11 on various machines without ever having any trouble. Ditto ... in fact, I do that on my desktop and have yet to hit a problem ... -STABLE *is* generally very stable ... Same here. However, if you want (or need) to track stable, there are certain possibilities to avoid trouble. Of course watching the -stable mailing list (and possibly even -cvs-all) and reading /usr/src/UPDATING should be a must. But there are more things that can be done. On important production machines, it might be a good idea to track -stable with some delay. For example, always update to the -stable date of 4 weeks ago (using the -D option of cvs, or the date= keyword of cvsup), after making sure that no critical problems have been reported in the mailing list in the past 4 weeks. Chances are that critical bugs are detected and fixed pretty quickly in the -stable branch. And of course: Always make sure that you have good backups. But that's even true if you don't track -stable. Best regards Oliver PS: Some people think that a RAID1 (mirror) is a substitute for a backup. It's not. -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. A language that doesn't have everything is actually easier to program in than some that do. -- Dennis M. Ritchie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On 9/9/06, Mark Andrews [EMAIL PROTECTED] wrote: Yeah, -STABLE is what you should run if you want stable code, right? No. STABLE means STABLE API. If you want stable code you run releases. Between releases stable can become unstable. Think of stable as permanent BETA code. Changes have passed the first level of testing in current which is permanent ALPHA code. No, this is what it means now. I've been running FreeBSD since 1.1, and -STABLE used to mean exactly that. The developement branch was -C, and -S was where things went after extensive testing. You were not allowed to break -S or Jordan would rip your fingers off. This change to the current structure wasn't meant to be permanent when it was done (between 4 and 5, IIRC), and was only done out of necessity because the changes across that major release were huge. FreeBSD needs an interim track that mirrors what -STABLE used to be, which is a track between point releases that can be relied upon (and RELEASE_x_y doesn't work, since it only addresses security and bugs deemed worthy, which most aren't). -- Jamie Bowden -- It was half way to Rivendell when the drugs began to take hold Hunter S Tolkien Fear and Loathing in Barad Dur Iain Bowen [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Vivek Khera schrieb: On Sep 12, 2006, at 6:23 PM, hackmiester (Hunter Fuller) wrote: -STABLE is still a development branch without guarantee of a stable and working operating system. Hahahahaha... That's ironic... No, just misinterpretation of which attribute of the system to which the word stable applies. Do you really think I misinterpreted the meaning of -STABLE? *I* think most people misinterprete -STABLE because the first thing that comes to mind is runtime stability. The same issue exists in the GNU/Debian Linux world: Debian stable doesn't mean that the system run always rock-solid and works perfectly, but rather the state of software is stable, i.e. maintainers ensure 100% compatibility between updates. Regards Björn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
hackmiester (Hunter Fuller) schrieb: On 12 September 2006, at 02:06, Björn König wrote: Karl Denninger schrieb: This is not cool folks. I think you misunderstood what -STABLE means. (Or maybe I do?) -STABLE is still a development branch without guarantee of a stable and working operating system. Hahahahaha... That's ironic... That wasn't meant to be ironic. Years of experience and observations of development lead to this conclusion. Regards Björn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Thu, Sep 14, 2006 at 11:44:12AM -0400, Jamie Bowden wrote: On 9/9/06, Mark Andrews [EMAIL PROTECTED] wrote: Yeah, -STABLE is what you should run if you want stable code, right? No. STABLE means STABLE API. If you want stable code you run releases. Between releases stable can become unstable. Think of stable as permanent BETA code. Changes have passed the first level of testing in current which is permanent ALPHA code. No, this is what it means now. I've been running FreeBSD since 1.1, and -STABLE used to mean exactly that. The developement branch was -C, and -S was where things went after extensive testing. You were not allowed to break -S or Jordan would rip your fingers off. This change to the current structure wasn't meant to be permanent when it was done (between 4 and 5, IIRC), and was only done out of necessity because the changes across that major release were huge. FreeBSD needs an interim track that mirrors what -STABLE used to be, which is a track between point releases that can be relied upon (and RELEASE_x_y doesn't work, since it only addresses security and bugs deemed worthy, which most aren't). YES [bar]. Until then I'm wedged into running -RELEASE (and occasionally praying to the computer gods. -- Jamie Bowden -- It was half way to Rivendell when the drugs began to take hold Hunter S Tolkien Fear and Loathing in Barad Dur Iain Bowen [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On 14 September 2006, at 14:05, Björn König wrote: hackmiester (Hunter Fuller) schrieb: On 12 September 2006, at 02:06, Björn König wrote: Karl Denninger schrieb: This is not cool folks. I think you misunderstood what -STABLE means. (Or maybe I do?) -STABLE is still a development branch without guarantee of a stable and working operating system. Hahahahaha... That's ironic... That wasn't meant to be ironic. Years of experience and observations of development lead to this conclusion. RIght. All i can say, though, is that someone that doesn't know any better would probably not think Oh! That means that upgrades are possible between releases, and not that my system will actually run, or anything! It just seems it'd be quite a cause of confusion. Regards Björn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] -- hackmiester (Hunter Fuller) svinx yknow when you go to a party, and everyones hooked up except one guy and one girl svinx and so they look at each other like.. do we have to? svinx intel nvidia must be lookin at each other like that right now Phone Voice: +1 251 589 6348 Fax: Call the voice number and ask. Email General chat: [EMAIL PROTECTED] Large attachments: [EMAIL PROTECTED] SPS-related stuff: [EMAIL PROTECTED] IM AIM: hackmiester1337 Skype: hackmiester31337 YIM: hackm1ester Gtalk: hackmiester MSN: [EMAIL PROTECTED] Xfire: hackmiester ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Thu, Sep 14, 2006 at 05:34:08PM -0500, hackmiester (Hunter Fuller) wrote: On 14 September 2006, at 14:05, Bj?rn K?nig wrote: hackmiester (Hunter Fuller) schrieb: On 12 September 2006, at 02:06, Bj?rn K?nig wrote: Karl Denninger schrieb: This is not cool folks. I think you misunderstood what -STABLE means. (Or maybe I do?) -STABLE is still a development branch without guarantee of a stable and working operating system. Hahahahaha... That's ironic... That wasn't meant to be ironic. Years of experience and observations of development lead to this conclusion. RIght. All i can say, though, is that someone that doesn't know any better would probably not think Oh! That means that upgrades are possible between releases, and not that my system will actually run, or anything! It just seems it'd be quite a cause of confusion. Anyone who is confused but doesn't attempt to enlighten themselves by reading the provided documentation deserves to stay confused :) Kris pgpdu8UO4NIuT.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Friday 15 September 2006 01:15, Kris Kennaway wrote: Anyone who is confused but doesn't attempt to enlighten themselves by reading the provided documentation deserves to stay confused :) What if they're unaware of their own confusion? Cheers Benjamin pgpvrWdyprhGN.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Thu, 14 Sep 2006, Jamie Bowden wrote: No, this is what it means now. I've been running FreeBSD since 1.1, and -STABLE used to mean exactly that. The developement branch was -C, and -S was where things went after extensive testing. You were not allowed to break -S or Jordan would rip your fingers off. Ah, QA through fear of the mighty hand of Jordan coming flying out your monitor and ripping your fingers off :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On 15/09/2006 01:37, Benjamin Lutz wrote: On Friday 15 September 2006 01:15, Kris Kennaway wrote: Anyone who is confused but doesn't attempt to enlighten themselves by reading the provided documentation deserves to stay confused :) What if they're unaware of their own confusion? I guess they get what they deserves ;) Is there a be better source of enlightenment than a handbook? To quote[1]: --% 21.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. --% Regards, Karol [1]http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html -- Karol Kwiatkowski freebsd at orchid dot homeunix dot org OpenPGP: http://www.orchid.homeunix.org/carlos/gpg/0x06E09309.asc signature.asc Description: OpenPGP digital signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sep 12, 2006, at 6:23 PM, hackmiester (Hunter Fuller) wrote: -STABLE is still a development branch without guarantee of a stable and working operating system. Hahahahaha... That's ironic... No, just misinterpretation of which attribute of the system to which the word stable applies.
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, Sep 09, 2006 at 12:38:13PM -0500, Karl Denninger wrote: This is not cool folks. I'm really sorry for the breakage. I'm trying to treat -STABLE very gently, unfortunately this time I made a mistake. The change was committed to HEAD at 9 August. The change fixed one bug, but introduced another, which I didn't expected. The change seemed to be trivial and I only tested that it fixes the bug I was tracking down, I haven't looked for regressions. After nearly one month in HEAD, I MFCed the change (at 4 September), because I wanted it to be released in -BETAs, so people can test it if they already didn't in HEAD and I was quite sure that after 1 month in HEAD the change is ok. I found the problem after 4 days (at 8 September) and backed the change out from the RELENG_6 branch. Once again, I'm really sorry, I'm trying not to make such surprises to the users, unfortunately it sometimes happens and you have to be ready that many changes goes to -STABLE branch just before release, so they can be tested by a wider audience. That's why we prepare -BETAs and not release -RELEASEs immediately. I'm not writting this to justify my mistake, just trying to show how you can avoid such bad days in the future. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpSmq7KzBDhd.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Wed, Sep 13, 2006 at 04:46:05PM +0200, Pawel Jakub Dawidek wrote: On Sat, Sep 09, 2006 at 12:38:13PM -0500, Karl Denninger wrote: This is not cool folks. I'm really sorry for the breakage. I'm trying to treat -STABLE very gently, unfortunately this time I made a mistake. The change was committed to HEAD at 9 August. The change fixed one bug, but introduced another, which I didn't expected. The change seemed to be trivial and I only tested that it fixes the bug I was tracking down, I haven't looked for regressions. Well, after this lengthy discussion, I've switched to -RELEASE. -STABLE just ain't... We all realize that none of us would put out a buggy release--not even -CURRENT. But let me ask the next obvious question. How difficult would it be to build a regression test, or suite of tests? Obviously, this could be done over months - years. (In my last lifetime as a hacker I was in the kernel test group [a BSD-4.4 based release on new architecture]. ) It's a bit hard to believe that with all the genius in this effort, that no regression testing is done. gary -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sep 13, 2006, at 11:15 AM, Gary Kline wrote: Well, after this lengthy discussion, I've switched to -RELEASE. -STABLE just ain't... We all realize that none of us would put out a buggy release--not even -CURRENT. But let me ask the next obvious question. How difficult would it be to build a regression test, or suite of tests? There are already a number of regression tests under /usr/src/tools/ regression; Peter Holm has additional stress testing tools at http://www.holm.cc/ stress/ -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Chuck Swiger wrote: On Sep 13, 2006, at 11:15 AM, Gary Kline wrote: ... How difficult would it be to build a regression test, or suite of tests? There are already a number of regression tests under /usr/src/tools/ regression; Are they part of an (automated) tinderbox system somewhere ? regards, Hans Lambermont ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Wed, Sep 13, 2006 at 11:15:04AM -0700, Gary Kline wrote: On Wed, Sep 13, 2006 at 04:46:05PM +0200, Pawel Jakub Dawidek wrote: On Sat, Sep 09, 2006 at 12:38:13PM -0500, Karl Denninger wrote: This is not cool folks. I'm really sorry for the breakage. I'm trying to treat -STABLE very gently, unfortunately this time I made a mistake. The change was committed to HEAD at 9 August. The change fixed one bug, but introduced another, which I didn't expected. The change seemed to be trivial and I only tested that it fixes the bug I was tracking down, I haven't looked for regressions. Well, after this lengthy discussion, I've switched to -RELEASE. -STABLE just ain't... We all realize that none of us would put out a buggy release--not even -CURRENT. But let me ask the next obvious question. How difficult would it be to build a regression test, or suite of tests? Obviously, this could be done over months - years. (In my last lifetime as a hacker I was in the kernel test group [a BSD-4.4 based release on new architecture]. ) It's a bit hard to believe that with all the genius in this effort, that no regression testing is done. I'm trying to implement regression tests to the code I add. You can find them in /usr/src/tools/regression/: geom_concat 2 files, 2 tests geom_eli15 files, 5818 tests geom_gate 3 files, 6 tests geom_mirror 7 files, 27 tests geom_nop2 files, 2 tests geom_raid3 12 files, 13 tests geom_shsec 2 files, 6 tests geom_stripe 2 files, 2 tests ipsec 1 file, 306 tests redzone91 file, 6 tests usr.bin/pkill 27 files, 49 tests As I said already, I mistakenly thought the change was trivial and the only thing I tested was if it fixes a bug I was tracking down back then. We dicuss from time to time that we should have service simlar to tinderbox, which will run regression tests regularly and report regressions to the mailing lists - the more we automate the smaller chance for a human mistake like mine. Unfortunately this is not yet done. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp2bvrpeTG1I.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Wed, Sep 13, 2006 at 10:26:03PM +0200, Pawel Jakub Dawidek wrote: On Wed, Sep 13, 2006 at 11:15:04AM -0700, Gary Kline wrote: On Wed, Sep 13, 2006 at 04:46:05PM +0200, Pawel Jakub Dawidek wrote: On Sat, Sep 09, 2006 at 12:38:13PM -0500, Karl Denninger wrote: This is not cool folks. I'm really sorry for the breakage. I'm trying to treat -STABLE very gently, unfortunately this time I made a mistake. The change was committed to HEAD at 9 August. The change fixed one bug, but introduced another, which I didn't expected. The change seemed to be trivial and I only tested that it fixes the bug I was tracking down, I haven't looked for regressions. Well, after this lengthy discussion, I've switched to -RELEASE. -STABLE just ain't... We all realize that none of us would put out a buggy release--not even -CURRENT. But let me ask the next obvious question. How difficult would it be to build a regression test, or suite of tests? Obviously, this could be done over months - years. (In my last lifetime as a hacker I was in the kernel test group [a BSD-4.4 based release on new architecture]. ) It's a bit hard to believe that with all the genius in this effort, that no regression testing is done. I'm trying to implement regression tests to the code I add. You can find them in /usr/src/tools/regression/: geom_concat 2 files, 2 tests geom_eli15 files, 5818 tests geom_gate 3 files, 6 tests geom_mirror 7 files, 27 tests geom_nop2 files, 2 tests geom_raid3 12 files, 13 tests geom_shsec 2 files, 6 tests geom_stripe 2 files, 2 tests ipsec 1 file, 306 tests redzone91 file, 6 tests usr.bin/pkill 27 files, 49 tests As I said already, I mistakenly thought the change was trivial and the only thing I tested was if it fixes a bug I was tracking down back then. We dicuss from time to time that we should have service simlar to tinderbox, which will run regression tests regularly and report regressions to the mailing lists - the more we automate the smaller chance for a human mistake like mine. Unfortunately this is not yet done. You're right in saying that the more automation, the more stability. Hats off for all this good work (from somebody who has been there before:) This is the kind of thing tht needs to be done (i) to catch bugs before they are committed, and (ii) to make BSD all the more trustworthy and bullet-proof. HAving run FBSD since 2.0.5 and only *one* fatal trap is pretty hard to beat. gary -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?! - back to Pawel
On Wed, Sep 13, 2006 at 04:46:05PM +0200, Pawel Jakub Dawidek wrote: On Sat, Sep 09, 2006 at 12:38:13PM -0500, Karl Denninger wrote: This is not cool folks. I'm really sorry for the breakage. I'm trying to treat -STABLE very gently, unfortunately this time I made a mistake. (elided) Thank you Pawel for the explanation. I understand that things go wrong; as a software developer I've let bad code out of the barn before. I try like hell not to have it happen, but it has The explanation is appreciated. BTW, part of the issue here with the -BETA thing is that there's no clear timeline on this available to people. I certainly was not aware that you were in a pre-check period to locking down the code to start the process of burning the next minor official rev. BTW, if this is indeed the case, you guys definitely need to look at the PR I filed on the Rcoketport driver. That problem either needs to be found and taken care of or those boards need to come out of the supported hardware list for the next release - its definitely broken, and the cause is not something immediately obvious (or I would have fixed it by now!) I AM efforting this but its its only got a moderate priority around here right now. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?! - back to Pawel
On Sep 13, 2006, at 21:00, Karl Denninger wrote: BTW, part of the issue here with the -BETA thing is that there's no clear timeline on this available to people. I certainly was not aware that you were in a pre-check period to locking down the code to start the process of burning the next minor official rev. Some upcoming release information is available online: http://www.freebsd.org/releng/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Tue, 12 Sep 2006, Steve O'Hara-Smith wrote: On Tue, 12 Sep 2006 10:55:48 -0500 Greg Barniskis [EMAIL PROTECTED] wrote: If you /track/ STABLE by frequently cvsupping it and rebuilding your system, you will very likely encounter a serious problem sooner or later. That's why tracking it is not recommended for production systems. I did exactly that all the way from 2.0 to 4.11 on various machines without ever having any trouble. Ditto ... in fact, I do that on my desktop and have yet to hit a problem ... -STABLE *is* generally very stable ... Stupid question here ... if -STABLE shouldn't be tracked, who exactly is doing testing on it? Those doing the work on -CURRENT, I would imagine, are tracking -CURRENT, and testing the code put in there for bugs ... when deemed 'bug free', then its being MFCd to -STABLE, but if those of us that *are* tracking -STABLE stop'd tracking it ... who would be testing it? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Thu, Sep 14, 2006 at 01:37:53AM -0300, Marc G. Fournier wrote: On Tue, 12 Sep 2006, Steve O'Hara-Smith wrote: On Tue, 12 Sep 2006 10:55:48 -0500 Greg Barniskis [EMAIL PROTECTED] wrote: If you /track/ STABLE by frequently cvsupping it and rebuilding your system, you will very likely encounter a serious problem sooner or later. That's why tracking it is not recommended for production systems. I did exactly that all the way from 2.0 to 4.11 on various machines without ever having any trouble. Ditto ... in fact, I do that on my desktop and have yet to hit a problem ... -STABLE *is* generally very stable ... Stupid question here ... if -STABLE shouldn't be tracked No-one's said that, so yeah, not the best question ;^) Kris pgpBQxxydV6Mf.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Marc G. Fournier wrote: On Tue, 12 Sep 2006, Steve O'Hara-Smith wrote: On Tue, 12 Sep 2006 10:55:48 -0500 Greg Barniskis [EMAIL PROTECTED] wrote: If you /track/ STABLE by frequently cvsupping it and rebuilding your system, you will very likely encounter a serious problem sooner or later. That's why tracking it is not recommended for production systems. I did exactly that all the way from 2.0 to 4.11 on various machines without ever having any trouble. Ditto ... in fact, I do that on my desktop and have yet to hit a problem ... -STABLE *is* generally very stable ... Stupid question here ... if -STABLE shouldn't be tracked, who exactly is doing testing on it? Those doing the work on -CURRENT, I would imagine, are tracking -CURRENT, and testing the code put in there for bugs ... when deemed 'bug free', then its being MFCd to -STABLE, but if those of us that *are* tracking -STABLE stop'd tracking it ... who would be testing it? It is not that you should not track it but where you should be tracking/testing it. Not on critical production servers would be a good start ;-) -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Karl Denninger schrieb: This is not cool folks. I think you misunderstood what -STABLE means. (Or maybe I do?) -STABLE is still a development branch without guarantee of a stable and working operating system. -STABLE guarantees that interfaces remain stable. If you want reliability then jump from release to release. Regards Björn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sep 12, 2006, at 3:06 AM, Björn König wrote: -STABLE is still a development branch without guarantee of a stable and working operating system. -STABLE guarantees that interfaces remain stable. If you want reliability then jump from release to release. If you want reliability, then you need to do your own testing on your own hardware on your own application prior to replacing your working version with the new one. Never rely on anyone else saying Yeah, it will work. It will come back and bite you where you don't want to be bit. The other side of this is don't replace what works and just leave things as they are.
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vivek Khera wrote: | If you want reliability, then you need to do your own testing on your | own hardware on your own application prior to replacing your working | version with the new one. Never rely on anyone else saying Yeah, it | will work. It will come back and bite you where you don't want to be bit. | | The other side of this is don't replace what works and just leave | things as they are. I must say that this one critical point is what made me choose FreeBSD over Linux way back in ~1992. It is possible, indeed almost mandatory in a commercial setting, to build a local repository containing the OS and *everything* required to build it. Good change management is not about tracking the latest and greatest, it's about being able to make sensible decisions about which changes to implement, when and, most of all, knowing why. Security isn't just about firewalls, it's about business continuity too, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFBr7xQv9rrgRC1JIRAnboAJ4vHl7UAF149CavttzqVwD/r8aIlgCggmY8 JyW4le67COyphcFoUUbZ7ng= =0rDL -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Tue, Sep 12, 2006 at 09:06:15AM +0200, Bj?rn K?nig wrote: Karl Denninger schrieb: This is not cool folks. I think you misunderstood what -STABLE means. (Or maybe I do?) -STABLE is still a development branch without guarantee of a stable and working operating system. -STABLE guarantees that interfaces remain stable. If you want reliability then jump from release to release. Regards Bj?rn You've never been able to get reliability by jumping from release to release, and every time someone comes in the lists to complain about something being broken in -RELEASE, the advice is to go to and track -STABLE! Guys, what's written in a handbook may be all well and good, but its what really happens that matters - and this is what has really happened for the last ten years with FreeBSD! I don't think its too much to ask that before something is MFC'd back to -STABLE from -CURRENT that it at least be tested for the most common functionality (that is, does it work at all?) In this case all that someone had to do was boot the system and then detach and reattach a mirror component - the most basic of functionality - to detect that the patch was bad. That obviously wasn't done in this instance. I understand that finding corner cases and expecting exhaustive testing is unreasonable from a free project - even in a -RELEASE we don't get that. But this wasn't a corner case - it was a situation where absolutely zero testing was performed before the MFC was sent back to the source tree. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Tue, Sep 12, 2006 at 09:59:02AM -0400, Vivek Khera wrote: On Sep 12, 2006, at 3:06 AM, Bj?rn K?nig wrote: -STABLE is still a development branch without guarantee of a stable and working operating system. -STABLE guarantees that interfaces remain stable. If you want reliability then jump from release to release. If you want reliability, then you need to do your own testing on your own hardware on your own application prior to replacing your working version with the new one. Never rely on anyone else saying Yeah, it will work. It will come back and bite you where you don't want to be bit. The other side of this is don't replace what works and just leave things as they are. That'd be nice - but in this case the reason for the replacement was that there's SERIOUS breakage in the serial drivers (at least the Rocketport ones, and perhaps more) in 6.x, which was what prompted the update. Finding a totally-unrelated thing MFCd back with zero testing was QUITE a surpriseand not something I would have tested for ANYWAY, since the commitlog for sys and this module suggested that the change made to that section of code was in fact to remove some inappropriate comments - not change functionality in a way that could potentially cause this sort of breakage! -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Hi. On Tue, Sep 12, 2006 at 09:15:47AM -0500, Karl Denninger wrote: I don't think its too much to ask that before something is MFC'd back to -STABLE from -CURRENT that it at least be tested for the most common functionality (that is, does it work at all?) In this case all that someone had to do was boot the system and then detach and reattach a mirror component - the most basic of functionality - to detect that the patch was bad. Thank god, nothing really can happen, if you deploy a new -STABLE on your servers, since of course before deploying a new piece of software it's being tested on a non-prod test setup, where you'll notice such apparent problems - especially when using -STABLE, where you never know, if you are probably just in the middle of a bigger commit. So, since nothing important could break, what's the hassle all about? - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Karl Denninger wrote: You've never been able to get reliability by jumping from release to release, eh? Been doing that for 10 years without a single significant problem. Granted, we've been lucky enough here not to encounter (a) flakier hardware components and/or (b) flakier combos of drivers apps configs heavy loads (a.k.a. bugs in FreeBSD) that other folks admittedly have encountered in the most painful ways. Releases aren't guaranteed to be perfect, nothing is, but plenty of users have no complaints at all about release point reliability. They're just not posting their non-problems to the lists. and every time someone comes in the lists to complain about something being broken in -RELEASE, the advice is to go to and track -STABLE! Maybe splitting hairs, but advising a user with a problem to try using the -STABLE code that exists at the time of the problem report is really not the same as advising them to /track/ STABLE. If you /track/ STABLE by frequently cvsupping it and rebuilding your system, you will very likely encounter a serious problem sooner or later. That's why tracking it is not recommended for production systems. On the other hand if you update a production system to a point in time of STABLE that fixes a particular bug that plagued a release point, and then you don't update again until the next release point or security advisory, you will very likely find joy. -- Greg Barniskis, Computer Systems Integrator South Central Library System (SCLS) Library Interchange Network (LINK) gregb at scls.lib.wi.us, (608) 266-6348 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Tue, 12 Sep 2006 10:55:48 -0500 Greg Barniskis [EMAIL PROTECTED] wrote: If you /track/ STABLE by frequently cvsupping it and rebuilding your system, you will very likely encounter a serious problem sooner or later. That's why tracking it is not recommended for production systems. I did exactly that all the way from 2.0 to 4.11 on various machines without ever having any trouble. -- C:WIN | Directable Mirror Arrays The computer obeys and wins.| A better way to focus the sun You lose and Bill collects. |licences available see |http://www.sohara.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Greg Barniskis wrote: Karl Denninger wrote: and every time someone comes in the lists to complain about something being broken in -RELEASE, the advice is to go to and track -STABLE! Maybe splitting hairs, but advising a user with a problem to try using the -STABLE code that exists at the time of the problem report is really not the same as advising them to /track/ STABLE. If you /track/ STABLE by frequently cvsupping it and rebuilding your system, you will very likely encounter a serious problem sooner or later. That's why tracking it is not recommended for production systems. On the other hand if you update a production system to a point in time of STABLE that fixes a particular bug that plagued a release point, and then you don't update again until the next release point or security advisory, you will very likely find joy. See my similar comment that echoes Karl's. Now go back and read what Karl said. He's not tracking -STABLE on a production box, he updated to -STABLE to fix an existing problem. What bit him in the ass is a problem with code that in theory had not changed and _was_supposed_ to have been tested. That is, it was working, he upgraded, as everyone tells you to do, to get fixes to -RELEASE bugs, not to track -STABLE. John -- John T. Farmer Owner CTO GoldSword Systems [EMAIL PROTECTED] 865-691-6498 Knoxville TN Consulting, Design, Development of Networks Software ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
At 10:15 AM 9/12/2006, Karl Denninger wrote: On Tue, Sep 12, 2006 at 09:06:15AM +0200, Bj?rn K?nig wrote: Karl Denninger schrieb: This is not cool folks. I think you misunderstood what -STABLE means. (Or maybe I do?) -STABLE is still a development branch without guarantee of a stable and working operating system. -STABLE guarantees that interfaces remain stable. If you want reliability then jump from release to release. Regards Bj?rn You've never been able to get reliability by jumping from release to release, I think FreeBSD does not work for everyone with every setup, but works really well for some number of people. For me, I am in b). In fact it works really well for me and the some 250 boxes I look after of varying age and configs... There have been some unfortunate bugs, but I take that as part of what FreeBSD is-- a volunteer project. If FreeBSD releases have *never* worked for you (I will take your word you are not being childish and exaggerating here), why on earth are you using FreeBSD ? Also, what are you comparing FreeBSD to, where the RELEASE works for everyone out of the box for ever and ever ? You cant mean Windows, as they release monthly updates-- some of which after having gone through tens of thousands of dollars of regression testing (FreeBSD does not have an army of employees to do planned regression testing let alone tens of thousands of dollars), and manage to introduce BIGGER bugs than they were fixing like they did last month with Win2k. You cant mean LINUX as they seem to be doing a kernel a month (or more) recently. Which OS are you talking about that is so perfect from release to release ? ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Karl Denninger wrote: You've never been able to get reliability by jumping from release to release, I think there are a lot of users who disagree with you on that one. and every time someone comes in the lists to complain about something being broken in -RELEASE, the advice is to go to and track -STABLE! These are different issues. I don't think its too much to ask that before something is MFC'd back to -STABLE from -CURRENT that it at least be tested for the most common functionality (that is, does it work at all?) In this case all that someone had to do was boot the system and then detach and reattach a mirror component - the most basic of functionality - to detect that the patch was bad. That obviously wasn't done in this instance. No one has disagreed with you about this. Several people have apologized already. It's past time that you got over it. That said, no matter how stable (in the dictionary term of the word) a given branch of FreeBSD is (or is not) at any given time, nothing replaces the need to test changes/updates yourself, on non-production hardware, before deploying them to anything you care about. That is just as true of FreeBSD as it is of any commercial software. Time to move on here folks, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Karl Denninger wrote: I don't think its too much to ask that before something is MFC'd back to -STABLE from -CURRENT that it at least be tested for the most common functionality (that is, does it work at all?) In this case all that someone had to do was boot the system and then detach and reattach a mirror component - the most basic of functionality - to detect that the patch was bad. That obviously wasn't done in this instance. I understand that finding corner cases and expecting exhaustive testing is unreasonable from a free project - even in a -RELEASE we don't get that. But this wasn't a corner case - it was a situation where absolutely zero testing was performed before the MFC was sent back to the source tree. So when can the FreeBSD Foundation expect your donation of computers for the purpose of GEOM testing? -- Darren Pilgrim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On 12 September 2006, at 02:06, Björn König wrote: Karl Denninger schrieb: This is not cool folks. I think you misunderstood what -STABLE means. (Or maybe I do?) -STABLE is still a development branch without guarantee of a stable and working operating system. Hahahahaha... That's ironic... (For lack of a better word, really.) -STABLE guarantees that interfaces remain stable. If you want reliability then jump from release to release. Regards Björn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] -- hackmiester (Hunter Fuller) svinx yknow when you go to a party, and everyones hooked up except one guy and one girl svinx and so they look at each other like.. do we have to? svinx intel nvidia must be lookin at each other like that right now Phone Voice: +1 251 589 6348 Fax: Call the voice number and ask. Email General chat: [EMAIL PROTECTED] Large attachments: [EMAIL PROTECTED] SPS-related stuff: [EMAIL PROTECTED] IM AIM: hackmiester1337 Skype: hackmiester31337 YIM: hackm1ester Gtalk: hackmiester MSN: [EMAIL PROTECTED] Xfire: hackmiester ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 11:59:10AM +1000, Mark Andrews wrote: Yeah, -STABLE is what you should run if you want stable code, right? No. STABLE means STABLE API. If you want stable code you run releases. Between releases stable can become unstable. Think of stable as permanent BETA code. Changes have passed the first level of testing in current which is permanent ALPHA code. Most of the time beta code is perfectly fine to run but occasionally things will go wrong. The point of BETA code is to catch those errors that escape detection in the ALPHA stage before they make it into a release. That is done by having a wider diversity of clients run the BETA code. Occasionally you have bugs that make it through both the ALPHA and BETA stages. Of course this assumes that -RELEASE is actually stable and fully suitable for production use. As soon as you find a bug that you can't live with in -RELEASE, you have darn few options other than to updade to -STABLE, especially if there's a commit in the tree that appears to fix the bug in -STABLE. Once the -RELEASE branch is taken, code updates there STOP. Not even Microsoft expects people to live from release to release without bug fixes! In the 10 years I've been running FreeBSD in a production environment I've yet to find a -RELEASE branch that is actually suitable for production use for the duration between -RELEASEs; inevitably a bug that I can't live with requires that I update the source, and what does one update to in this instance? -STABLE. If the project wishes to have -RELEASE be the stable point then bug fixes (once FULLY tested) must be back-ported to -RELEASE - otherwise the appearance of a bug you can't live with gives you no other real option than to run the -STABLE track. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, 10 Sep 2006, Karl Denninger wrote: Once the -RELEASE branch is taken, code updates there STOP. I take it you haven't read the text in the handbook that has been linked to by a few posters. You can track changes to a particular release - say by using RELENG_6_1 rather than RELENG_6. In which case, would you still say you are tracking STABLE? -- patrick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick J Okui Sent: Sunday, September 10, 2006 10:22 AM To: Karl Denninger Cc: freebsd-stable@freebsd.org Subject: Re: AGH! Guys, who's breaking -STABLE's GMIRROR code?! You can track changes to a particular release - say by using RELENG_6_1 rather than RELENG_6. In which case, would you still say you are tracking STABLE? Well, that depends. For security and critical fixes (as the handbook phrases it) you can track RELENG_6_1 (in the case of 6.1-RELEASE) and be happy. But what happens if the needed fix isn't security or critical in the minds of the FreeBSD developers? At that point you either need to wait for the next RELEASE, manually merge fixes into your production source (which depending on the fix(s) could be non-trivial) or cross your fingers and follow -STABLE. This problem isn't specific to FreeBSD (or unix in general) by Any means, of course. Sure, we could broaden the scope of RELENG_X_Y. Or introduce a new branch that's closer to -STABLE yet tuned for something like, security, critical and major fixes for production systems. I'm not sure either of those options are preferable, would be effective in alleviating the problem, or even workable in the first place. Personally, I've been served quite well for many years with the current configuration. Since I don't track -STABLE on anything important (or more accurately have yet NEEDED to do so), I've never been hit by any of these transient issues that crop up from time to time and can elicit loud complaints. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 03:21:33PM +, Patrick J Okui wrote: On Sun, 10 Sep 2006, Karl Denninger wrote: Once the -RELEASE branch is taken, code updates there STOP. I take it you haven't read the text in the handbook that has been linked to by a few posters. You can track changes to a particular release - say by using RELENG_6_1 rather than RELENG_6. In which case, would you still say you are tracking STABLE? Yes. If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition tracking -STABLE. Indeed, the current tag on my CVS tree is TRELENG_6! -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 01:13:31PM -0500, Karl Denninger wrote: On Sun, Sep 10, 2006 at 03:21:33PM +, Patrick J Okui wrote: On Sun, 10 Sep 2006, Karl Denninger wrote: Once the -RELEASE branch is taken, code updates there STOP. I take it you haven't read the text in the handbook that has been linked to by a few posters. You can track changes to a particular release - say by using RELENG_6_1 rather than RELENG_6. In which case, would you still say you are tracking STABLE? Yes. If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition tracking -STABLE. Indeed, the current tag on my CVS tree is TRELENG_6! Not the question he asked, please re-read. Kris pgpnBuAGsmW2l.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 02:36:31PM -0400, Kris Kennaway wrote: On Sun, Sep 10, 2006 at 01:13:31PM -0500, Karl Denninger wrote: On Sun, Sep 10, 2006 at 03:21:33PM +, Patrick J Okui wrote: On Sun, 10 Sep 2006, Karl Denninger wrote: Once the -RELEASE branch is taken, code updates there STOP. I take it you haven't read the text in the handbook that has been linked to by a few posters. You can track changes to a particular release - say by using RELENG_6_1 rather than RELENG_6. In which case, would you still say you are tracking STABLE? Yes. If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition tracking -STABLE. Indeed, the current tag on my CVS tree is TRELENG_6! Not the question he asked, please re-read. Kris Yes it is, in the general case; in any event if you track RELENG_6_1 you will get no bug fixes in general - security related items to filter back down but in general bug reports posted against a -RELEASE are, if addressed, put into -STABLE. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
From: Karl Denninger [EMAIL PROTECTED] To: freebsd-stable@freebsd.org Sent: Sunday, September 10, 2006 9:39 PM Yes it is, in the general case; in any event if you track RELENG_6_1 you will get no bug fixes in general - security related items to filter back down but in general bug reports posted against a -RELEASE are, if addressed, put into -STABLE. You would like untested fixes to hit the release version first? By the way, possible breakage of STABLE due MFC process was announced a good while ago... -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
You can track changes to a particular release - say by using RELENG_6_1 rather than RELENG_6. In which case, would you still say you are tracking STABLE? If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition tracking -STABLE. Damn, I'm confused now. Let me try and get this straight: CURRENT This is, by definition, broken a good part of the time, and is what it says, namely current, ie work in progress. STABLE This is broken some of the time and .. uh .. isn't really all that stable, actually. RELENG_n_m This is completely stable and only tracks security fixes. RELENG_n (RELENG_6 at the moment) Has somebody just said that RELENG_6 = STABLE? I'm going to guess then that RELENG_7 is CURRENT. No, this doesn't make sense to me at all. Indeed, the current tag on my CVS tree is TRELENG_6! Eh? T? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Michael Abbott wrote: Damn, I'm confused now. Let me try and get this straight: CURRENT This is, by definition, broken a good part of the time, and is what it says, namely current, ie work in progress. Yes. STABLE This is broken some of the time and .. uh .. isn't really all that stable, actually. STABLE means you can update FreeBSD along this branch without needing to recompile applications or kernel modules. This means that companies can ship binary drivers for their hardware and say this driver will work on FreeBSD 6.x (which isn't possible on Linux). The fact that there are occasionally bugs introduced... well, that's an inevitable consequence of the stable branches being development branches. RELENG_n_m This is completely stable and only tracks security fixes. Security fixes and critical errata. The requirements for something being committed to such a branch after the release are that: 1. It must be an important bugfix, and 2. I must be absolutely certain that nothing bad will ever happen as a result of someone updating a FreeBSD n.m system to the latest updates on RELENG_n_m. RELENG_n (RELENG_6 at the moment) Has somebody just said that RELENG_6 = STABLE? Yes. I'm going to guess then that RELENG_7 is CURRENT. No, this doesn't make sense to me at all. RELENG_7 doesn't exist yet. RELENG_7 will be 7-STABLE once it exists, some time in 2007. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 08:11:22PM +, Michael Abbott wrote: You can track changes to a particular release - say by using RELENG_6_1 rather than RELENG_6. In which case, would you still say you are tracking STABLE? If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition tracking -STABLE. Damn, I'm confused now. Let me try and get this straight: Perhaps this might help? http://home.nyc.rr.com/computertaijutsu/release.html -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Buffy: Well, that works out great. You won't tell anyone that I'm the Slayer, and I won't tell anyone you're a moron. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 08:11:22PM +, Michael Abbott wrote: Indeed, the current tag on my CVS tree is TRELENG_6! Eh? T? cd /usr/src cat CVS/Tag CVS places a T infront of the tag name in the Tag file. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
This should be documented somewhere clearly then, as my understanding was that -STABLE meant that anything MFCd back to it *was* tested and deemed stable ... and yes, I do run stable, and yes, I do expect to hit the occasional 'oopses', but blantant and obvious bugs due to insufficient testing, IMHO, doesn't classify as an 'oops' Guys, we're talking about software. Have you ever seen a piece of software which has been really bug-free? Not the hello-world, I'm talking about real software. Also, you should never go with -STABLE on a production server. I'm sure this has been made clear in the handbook. If it's really a that import server in production use, go with a RELEASE. -STABLE is not a technology playground as CURRENT but should be seen as a BETA testing system. If that's not the case, then why use RELEASE at all? Sure you may blame a developer for not testing enough but you're on your own if you use beta quality software on your production systems. As a developer I've seen many bugs which haven't been found during testing and I know it's nearly impossible to find _all_ bugs while testing. I've seen applications failing just because the user typed the wrong key at the wrong time (or an unexpected key). As a user I'm thankful for bugs being fast fixed bugs but on the other side I really know what I'm doing when using -STABLE software on my system. I do see this as a give-back to the community to find bugs early before -RELEASE. Also keep in mind most kernel hackers do kernel hacking in their spare time. Everyone using FreeBSD (or any other OS system) is profiting from their spare time and it's unfair to be not that polite. And back to the issue: The gmirror bug has already been fixed and I posted a note to the ML hours before the first who the f... did cause that bug post. A short look into ML postings would have made this thread needless. If you blame developers, then please shut off your computer. my2ct Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
in message [EMAIL PROTECTED], wrote Volker thusly... we're talking about software. Have you ever seen a piece of software which has been really bug-free? Not the hello-world, I'm talking Recently i read about which is more than hello-world ... They Write the Right Stuff http://www.fastcompany.com/online/06/writestuff.html ... but you did ask. - Parv -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
On Sun, Sep 10, 2006 at 07:33:25PM -0400, 'Anubhav A.' wrote: in message [EMAIL PROTECTED], wrote Volker thusly... we're talking about software. Have you ever seen a piece of software which has been really bug-free? Not the hello-world, I'm talking Recently i read about which is more than hello-world ... They Write the Right Stuff http://www.fastcompany.com/online/06/writestuff.html ... but you did ask. -- This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. -- But that just proves the point: despite all that careful engineering, one error each and a total of 17 errors != bug-free. Kris pgp7MKkCGgGI8.pgp Description: PGP signature
Re: Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
On 2006-09-11 01:33, 'Anubhav A.' wrote: in message [EMAIL PROTECTED], wrote Volker thusly... we're talking about software. Have you ever seen a piece of software which has been really bug-free? Not the hello-world, I'm talking Recently i read about which is more than hello-world ... They Write the Right Stuff http://www.fastcompany.com/online/06/writestuff.html ... but you did ask. - Parv Interesting article but I really do not believe even the shuttle software is 100% bug free. Just because there has been only one bug found in the last version, does not mean it's really guaranteed to be bug free. It's just: No one experienced one and no one discovered one more. On the other side they do not implement much new features every day and they do not have to care about hardware and market changes every other day. I suspect a lot of trouble even for NASA's mission does come from software bugs and who knows how many lifes can be accounted for software bugs. Remembering the first launch of a Ariane-5 rocket? It has been self destroyed because of nothing but a software bug. Or what about the first NAVY combat ship w/ steering controlled by Windows NT? Out of control by a blue screen... A developer can't always foresee the environment where his code will later work in and that is even causing trouble. And again, errors and mistakes are human. And those who shout out why didn't you test enough should ask themself, how much have THEY contributed to the community? The hackers are contributing enough (my view) and are really doing a good job. I do not care about HOW MANY bugs a beta quality piece of software does contain but what IMHO matters is the timeframe to FIX them and the FreeBSD project and other OS communities are good in that. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 10:15:20PM +0300, Reko Turja wrote: From: Karl Denninger [EMAIL PROTECTED] To: freebsd-stable@freebsd.org Sent: Sunday, September 10, 2006 9:39 PM Yes it is, in the general case; in any event if you track RELENG_6_1 you will get no bug fixes in general - security related items to filter back down but in general bug reports posted against a -RELEASE are, if addressed, put into -STABLE. You would like untested fixes to hit the release version first? By the way, possible breakage of STABLE due MFC process was announced a good while ago... No, I would like -STABLE to be treated as what it is claimed to be - BETA code, not ALPHA code. There's a huge difference between the two, and MFCing something back to -STABLE without testing the BASIC functionality of the module you're working with first does not fit the BETA model (it DOES fit the Alpha model.) This is coming from someone who has run FreeBSD in a production environment for basically 10 years, and has even sometimes used -CURRENT during that time (with full knowledge that running THAT is, indeed, ALPHA code!) -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 08:11:22PM +, Michael Abbott wrote: You can track changes to a particular release - say by using RELENG_6_1 rather than RELENG_6. In which case, would you still say you are tracking STABLE? If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition tracking -STABLE. Damn, I'm confused now. Let me try and get this straight: CURRENT This is, by definition, broken a good part of the time, and is what it says, namely current, ie work in progress. STABLE This is broken some of the time and .. uh .. isn't really all that stable, actually. RELENG_n_m This is completely stable and only tracks security fixes. Incorrect. This is completely FIXED, which is not the same thing as STABLE. Fixed in a broken state is still broken, aka the serial I/O problems in 6.x that I've found (and for which there is apparently no current fix in any of the branches of 6.x.) RELENG_n (RELENG_6 at the moment) Has somebody just said that RELENG_6 = STABLE? I'm going to guess then that RELENG_7 is CURRENT. No, this doesn't make sense to me at all. Indeed, the current tag on my CVS tree is TRELENG_6! Eh? T? As in Tag, which is the syntax that acutally shows up in the CVS directory under the source tree. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
Volker wrote: On 2006-09-11 01:33, 'Anubhav A.' wrote: in message [EMAIL PROTECTED], wrote Volker thusly... we're talking about software. Have you ever seen a piece of software which has been really bug-free? Not the hello-world, I'm talking Recently i read about which is more than hello-world ... They Write the Right Stuff http://www.fastcompany.com/online/06/writestuff.html ... but you did ask. - Parv Interesting article but I really do not believe even the shuttle software is 100% bug free. Just because there has been only one bug found in the last version, does not mean it's really guaranteed to be bug free. It's just: No one experienced one and no one discovered one more. On the other side they do not implement much new features every day and they do not have to care about hardware and market changes every other day. I suspect a lot of trouble even for NASA's mission does come from software bugs and who knows how many lifes can be accounted for software bugs. Remembering the first launch of a Ariane-5 rocket? It has been self destroyed because of nothing but a software bug. Or what about the first NAVY combat ship w/ steering controlled by Windows NT? Out of control by a blue screen... A developer can't always foresee the environment where his code will later work in and that is even causing trouble. And again, errors and mistakes are human. And those who shout out why didn't you test enough should ask themself, how much have THEY contributed to the community? The hackers are contributing enough (my view) and are really doing a good job. I do not care about HOW MANY bugs a beta quality piece of software does contain but what IMHO matters is the timeframe to FIX them and the FreeBSD project and other OS communities are good in that. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Sorry to be dense but what does MFCing mean. I have googled for it but can find nothing that explains it. Thanks, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
On 2006-09-11 02:25, Stephen Clark wrote: Sorry to be dense but what does MFCing mean. I have googled for it but can find nothing that explains it. Thanks, Steve Steve, MFC means merge from current (read as: merge from CURRENT [HEAD] cvs tree into the current -STABLE tree). I'm seeing -CURRENT as a playground for new features, technologies and support for latest hardware. If something has worked out there, the changes are merged from the -CURRENT tree into the (non-release) -STABLE tree. -STABLE has a broader audience and mistakes will probably being detected there. At a time before RELEASE date the -STABLE tree is being frozen (no new features are allowed to be merged into -STABLE) and after a testing phase (BETA / PRE-RELEASE) the code will be released. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[OT] Re: Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
On Mon, 11 Sep 2006 02:37:37 +0200, Volker [EMAIL PROTECTED] wrote: MFC means merge from current (read as: merge from CURRENT [HEAD] cvs tree into the current -STABLE tree). Way off-topic: I had a patch around my stuff to add this (and some others I don't remember now) to the wtf (1) base, or even a FreeBSD Glossary section in the handbook. It certainly wouldn't hurt to have one, and at least me would thank the brave fellow who did it :) -- Ricardo Nabinger Sanchez [EMAIL PROTECTED],wait4.org} Powered by FreeBSD Left to themselves, things tend to go from bad to worse. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Volker wrote: This should be documented somewhere clearly then, as my understanding was that -STABLE meant that anything MFCd back to it *was* tested and deemed stable ... and yes, I do run stable, and yes, I do expect to hit the occasional 'oopses', but blantant and obvious bugs due to insufficient testing, IMHO, doesn't classify as an 'oops' Guys, we're talking about software. Have you ever seen a piece of software which has been really bug-free? Not the hello-world, I'm talking about real software. Also, you should never go with -STABLE on a production server. I'm sure this has been made clear in the handbook. If it's really a that import server in production use, go with a RELEASE. -STABLE is not a technology playground as CURRENT but should be seen as a BETA testing system. If that's not the case, then why use RELEASE at all? Pardon me, but I do have to interject a very large laugh here. What's the first recommendation that's made _every_ time someone posts a problem with a -RELEASE installation? It's Well, go update to -STABLE and then we will might be able to help you. Simply put, running a -RELEASE means that you _are_ running software with _known_ problems. I'm very thankful for all the work that people put into FreeBSD. However, that doesn't blind me to problems with the current setup. It may be the best that we have, it may be better than the Linux world, but that doesn't mean that it solves all our problems and that we can't improve it. John(FreeBSD since 2.0.x on an AMD K5-100 with 16MB of ram...) -- John T. Farmer Owner CTO GoldSword Systems [EMAIL PROTECTED] 865-691-6498 Knoxville TN Consulting, Design, Development of Networks Software ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Karl Denninger wrote: No, I would like -STABLE to be treated as what it is claimed to be - BETA code, not ALPHA code. There's a huge difference between the two, and MFCing something back to -STABLE without testing the BASIC functionality of the module you're working with first does not fit the BETA model (it DOES fit the Alpha model.) This is coming from someone who has run FreeBSD in a production environment for basically 10 years, and has even sometimes used -CURRENT during that time (with full knowledge that running THAT is, indeed, ALPHA code!) I guess part of the problem is not enough of us running -CURRENT, so bugs can slip through into -STABLE via MFC (I know I'm guilty here - 2 boxes running -STABLE, none on -CURRENT) Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Hi! On Sat, Sep 09, 2006 at 12:38:13PM -0500, Karl Denninger wrote: This is not cool folks. ... I experienced the same problem - luckily on a lab machine. As much as I understand your anger, -stable is not guaranteed bug free. And to answer your question: RELENG_6_1 doesn't show this problem. I recommend running RELENG_X_Y instead of RELENG_X for recent values of X and Y on production systems, anyway. HTH, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Saturday 09 September 2006 19:38, Karl Denninger wrote: This is not cool folks. Want a refund? -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpabFdsW8NAv.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Yeah, -STABLE is what you should run if you want stable code, right? C'mon guys. This sort of thing belies a total lack of concern when changes are MFC'd into production branches of the code. This kind of thing is expected if you're running -CURRENT, but not -STABLE. How long would it have taken to actually test the change and detect this once it was put in? All of 30 seconds? -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind On Sat, Sep 09, 2006 at 08:23:10PM +0200, Max Laier wrote: On Saturday 09 September 2006 19:38, Karl Denninger wrote: This is not cool folks. Want a refund? -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, Sep 09, 2006 at 01:28:31PM -0500, Karl Denninger wrote: Yeah, -STABLE is what you should run if you want stable code, right? C'mon guys. This sort of thing belies a total lack of concern when changes are MFC'd into production branches of the code. This kind of thing is expected if you're running -CURRENT, but not -STABLE. How long would it have taken to actually test the change and detect this once it was put in? All of 30 seconds? Please try to calm down, getting angry on the mailing list is only going to make everyone else angry too. Kris pgpTIX8aPwctO.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, 9 Sep 2006, Karl Denninger wrote: Yeah, -STABLE is what you should run if you want stable code, right? C'mon guys. This sort of thing belies a total lack of concern when changes are MFC'd into production branches of the code. This kind of thing is expected if you're running -CURRENT, but not -STABLE. How long would it have taken to actually test the change and detect this once it was put in? All of 30 seconds? In this case, I don't know ... but I *do* know that I do hit a fair number of bugs that a simple 30 second test won't uncover ... a production box *can* and *will* tend to hit bugs that a test box won't, just because of the randomness of what is running on it ... trust me, I've had my share of headaches over the years, but it doesn't (and won't) deter me from running -STABLE, for the simple fact that if I don't, there is a good chance that those bugs that I do get lucky enough to hit won't get hit by anyone else and *someone* had to get it ;) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, Sep 09, 2006 at 04:04:40PM -0300, Marc G. Fournier wrote: On Sat, 9 Sep 2006, Karl Denninger wrote: Yeah, -STABLE is what you should run if you want stable code, right? C'mon guys. This sort of thing belies a total lack of concern when changes are MFC'd into production branches of the code. This kind of thing is expected if you're running -CURRENT, but not -STABLE. How long would it have taken to actually test the change and detect this once it was put in? All of 30 seconds? In this case, I don't know ... but I *do* know that I do hit a fair number of bugs that a simple 30 second test won't uncover ... a production box *can* and *will* tend to hit bugs that a test box won't, just because of the randomness of what is running on it ... trust me, I've had my share of headaches over the years, but it doesn't (and won't) deter me from running -STABLE, for the simple fact that if I don't, there is a good chance that those bugs that I do get lucky enough to hit won't get hit by anyone else and *someone* had to get it ;) Well sure, if its one of those corner cases I understand. This is the price of not doing FULL regression testing, and expecting that from a free project is unreasonable. Hell, you don't get that from Micro$oft, why would anyone think you'd get it here? But in this situation its not a corner case. I've got a (different) open issue on 6.x where it appears that SELECT on serial lines is badly screwed; this may be specific to the ROCKETPORT cards and it may not - not real sure yet. I reported that one recently too, and its giving me a 5-alarm migrane at the moment trying to find a workaround that actually functions. I can't find anything in the commit logs that would lead me to believe that the ttyio code has changed in a way that should have caused this, and the driver hasn't been updated either. That's a head-scratcher for a whole host of reasons with the first one being that I don't have the first clue where to look for the source of trouble (to use a pun.) Its not as simple as serial I/O doesn't work at all; it appears to be specific to using VMIN, non-blocking I/O and select() to handle multiple sources of input coming into a single thread. Now how often do people do this? I dunno. but what I do know is that the common single thread application works fine on the same port This is different. We're talking about the very basic functionality of the gmirror system - to be able to rebuild a disk that is out of sync. In this case my notice of the problem came in the form of a production machine that went down overnight - apparently, it would seem, during an attempt to back itself up using that functionality. It went down HARD and corrupted the root partition directory structure badly enough to prevent fsck from being able to rebuild it on an automated restart attempt, and what was worse, the bug caused the system to block in I/O permanently as of course when it came back up from the crash it tried to resync the out-of-date providers, making the reboot hang! So what I had was a production machine that couldn't be brought back up without significant wizardry at the physical console, and frankly, what it LOOKED LIKE at first blush was a double disk failure - one of those that's not supposed to happen things. I was very close to putting the day-old backup disk online - I'm darn glad I didn't, because the bug would have likely trashed THAT one too, and then I'd be both a day back on the data AND have an unstable system! Not good, especially when the commit log on the last delta to the gmirror code was basically removed uses of the F-word in comments; we're nice people. Uh, obviously not. The obvious question is how does the protocol for committing changes to -STABLE work if the committer isn't required to first test the basic function set of the module he/she modifies, on -STABLE, before those changes are MFC'd back into the -STABLE tree? I see that the (actual) code changes were backed out (apparently yesterday) and I've rebuilt the kernel with those, which has put the immediate fire out, but this is one of those instances where the usual check and balance process that is ADVERTISED as being present in -STABLE failed badly, and it failed simply due to a lack of checking at all! -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Yeah, -STABLE is what you should run if you want stable code, right? No. STABLE means STABLE API. If you want stable code you run releases. Between releases stable can become unstable. Think of stable as permanent BETA code. Changes have passed the first level of testing in current which is permanent ALPHA code. Most of the time beta code is perfectly fine to run but occasionally things will go wrong. The point of BETA code is to catch those errors that escape detection in the ALPHA stage before they make it into a release. That is done by having a wider diversity of clients run the BETA code. Occasionally you have bugs that make it through both the ALPHA and BETA stages. Mark -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
This should be documented somewhere clearly then, as my understanding was that -STABLE meant that anything MFCd back to it *was* tested and deemed stable ... and yes, I do run stable, and yes, I do expect to hit the occasional 'oopses', but blantant and obvious bugs due to insufficient testing, IMHO, doesn't classify as an 'oops' On Sun, 10 Sep 2006, Mark Andrews wrote: Yeah, -STABLE is what you should run if you want stable code, right? No. STABLE means STABLE API. If you want stable code you run releases. Between releases stable can become unstable. Think of stable as permanent BETA code. Changes have passed the first level of testing in current which is permanent ALPHA code. Most of the time beta code is perfectly fine to run but occasionally things will go wrong. The point of BETA code is to catch those errors that escape detection in the ALPHA stage before they make it into a release. That is done by having a wider diversity of clients run the BETA code. Occasionally you have bugs that make it through both the ALPHA and BETA stages. Mark -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote: This should be documented somewhere clearly then, as my understanding was that -STABLE meant that anything MFCd back to it *was* tested and deemed stable ... http://www.freebsd.org/doc/en_US.ISO8859-1/articles/version-guide/decision-points.html but blantant and obvious bugs due to insufficient testing, IMHO, doesn't classify as an 'oops' You've already made this point -- 3 times. What would you like us to do now, punish the committer? Simply reiterating your criticism and unhappiness isn't going to do anything to fix this problem (for which, of course, a fix has already been made), or the next one(s) either. It was an error, it's been fixed, may I suggest we move on to the next bug? mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote: This should be documented somewhere clearly then, as my understanding was that -STABLE meant that anything MFCd back to it *was* tested and deemed stable ... You mean like in the FreeBSD handbook? It's not anyone else's fault if you haven't read the documentation. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html Kris pgpJvUwwnTWKq.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, 9 Sep 2006, Mark Linimon wrote: On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote: This should be documented somewhere clearly then, as my understanding was that -STABLE meant that anything MFCd back to it *was* tested and deemed stable ... http://www.freebsd.org/doc/en_US.ISO8859-1/articles/version-guide/decision-points.html but blantant and obvious bugs due to insufficient testing, IMHO, doesn't classify as an 'oops' You've already made this point -- 3 times. What would you like us to do now, punish the committer? Huh? My first post on this thread was in defense of MFCng into STABLE and acknowledging that 'mistakes happen', and then this one ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, 9 Sep 2006, Kris Kennaway wrote: On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote: This should be documented somewhere clearly then, as my understanding was that -STABLE meant that anything MFCd back to it *was* tested and deemed stable ... You mean like in the FreeBSD handbook? It's not anyone else's fault if you haven't read the documentation. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html I swear, the last time I searched for a definition of STABLE vs CURRENT/HEAD, that wsan't there ... but, granted, that was a very very long time ago ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 12:55:42AM -0300, Marc G. Fournier wrote: On Sat, 9 Sep 2006, Kris Kennaway wrote: On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote: This should be documented somewhere clearly then, as my understanding was that -STABLE meant that anything MFCd back to it *was* tested and deemed stable ... You mean like in the FreeBSD handbook? It's not anyone else's fault if you haven't read the documentation. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html I swear, the last time I searched for a definition of STABLE vs CURRENT/HEAD, that wsan't there ... but, granted, that was a very very long time ago ... Well, now you know. Might be a good idea to reread the handbook and other documentation to bring yourself up to date on anything else you might have missed too. Kris pgpNQkqiGvM8J.pgp Description: PGP signature
