RE: Staying *really stable* in FreeBSD
Is there a reason why you took this off the list? On Wednesday, June 27, 2001 10:52 AM, Mike Porter [SMTP:[EMAIL PROTECTED]] wrote: On Wednesday 27 June 2001 07:11, you wrote: On Tuesday, June 26, 2001 5:07 PM, Chad R. Larson [SMTP:[EMAIL PROTECTED]] wrote: If anyone is taking votes, I disagree. The -STABLE branch is not -BETA in any way that I can see. It's simply a low key development branch. Changes are tested in -CURRENT before being merged into -STABLE, therefore there's nothing -BETA about it. While I agree with most of what you said, I disagree here. Just because *some* testing has been done, doesn't mean it isn't BETA. BETA software is generally believed to be pretty stable, just a few minor kinks to work out. At that point, getting it into the hands of the largest possible cross-section of users makes sense, becuase collectively they are more likely to excercise all of the features. Further, some features may work as intended when the user follows all the correct steps in the correct sequence, but how easy is it to get out of the sequence and break things? (Example (ok, its a bad/simplified example but it demonstrates the point): Actually ... it's a good example. So BETA testing takes place after a good deal of previous in house development happens. This is the alpha test stage. Why do you think they use beta (the SECOND letter of the greek alphbet) to denote the SECOND test? It implies that there is an alpha or first test before. thus -CURRENT is ALPHA level code, STABLE is BETA. That's also a relevent point. alpha and beta are generally used to describe testing sequences in/out of the developer circle. In a company, alpha testing is done by the developers or other employees of the company, while beta testing is done by providing the software to a select group of customers who have volunteered to test the software. This particular model falls apart when you have the FreeBSD development model. Reasons: 1) anyone who wants to test -CURRENT can, thus it doesn't fit typical expectation of alpha 2) the developers are generally also the users 3) The -STABLE branch is not *intended* to be for testing purposed only. It is *intended* to be a useable product. In the commercial world, a beta is NOT INTENDED for regular use, but for testing only. Thus, renaming the -STABLE branch would be a misnomer. Of course, if you assume that STABLE is BETA level code, then you can expect some glitches, and sometimes things WILL slip through the cracks and cause major headaches...but *in general* you should have fairly stable code, with a few bugs in it. You EXPECT (or SHOULD EXPECT) there to be bugs in itthat's part of the development effort. No, according the the handbook, you should not *expect* there to be bugs in -STABLE, You should be wary, as the handbook warns you, but my experience with -STABLE over the last two years is that it's generally pretty reliable. The handbook also states that you should subscribe to the stable mailing list if you intend to track -STABLE, so anyone following the hanbook is going to be well informed when breakage occurs. I believe the recent changes to the handbook did an excellent job of clearing this up. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Staying *really stable* in FreeBSD
On Sun, Jun 24, 2001 at 02:34:03AM -0700, Jordan Hubbard wrote: From: Juha Saarinen [EMAIL PROTECTED] Subject: RE: Staying *really stable* in FreeBSD Date: Sun, 24 Jun 2001 12:00:59 +1200 19.2.2.2. Who needs FreeBSD-STABLE? If you are a commercial user or someone who puts maximum stability of their FreeBSD system before all other concerns, you should consider tracking FreeBSD-STABLE. This is especially true if you have installed It's probably time to rewrite that paragraph substantially. It was something of a tactical error to encourage certain interest groups to run work in progress code, even if that work is very carefully bounded and kept in progress for the shortest periods possible. You just can't have a code base which is actually going places and having things actively updated (which is generally a really good idea, especially when the updates involved fixing bugs) and also guarantee that it's particularly usable for anything. Whether it builds flawlessly without warnings or not, it still represents a fairly significant unknown quantity until such time as you've frozen the code and spent a few weeks, at minimum, collecting user reports and making very carefully selected changes. We've also heard any number of suggestions for fixing the problem, from aggressive automated tagging (which would be tremendously expensive with CVS and not fix the builds but doesn't work problem) to extensive regression test suites that nobody seems to have time to actually write. As I said at the beginning, perhaps it's time to simply re-write the Handbook paragraph which inadvertently sells -stable as a solution for certain types of problems it was never meant to solve. Done. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- PGP signature
Re: Staying *really stable* in FreeBSD
On Wed, Jun 27, 2001 at 09:41:18AM -0500, Christopher Schulte wrote: At 11:44 PM 6/26/2001 +0100, Nik Clayton wrote: I've rewritten section 19.2.2.1 and 19.2.2.2 at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html Do people think this gets the point across any better? The patch branch (currently RELENG_4_3) should be introduced, perhaps mentioned here, Not yet. AIUI, the RELENG_4_3 branch is an experiment, and gives us the option of providing security fixes this way. I haven't seen a commitment[1] from the security officer team that they will actually do this. Until that happens I don't think it should be documented. N [1] Not a slur on the fine efforts of the security team. I mean that I haven't seen an e-mail that says Yes, any security fixes to RELENG_4 will *definitely* be made available on the RELENG_4_3 branch. -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- PGP signature
Re: Staying *really stable* in FreeBSD
On Wednesday 27 June 2001 09:44, Bill Moran wrote: Is there a reason why you took this off the list? my mistake (or my mailer's depending on how you look at it). If the majordomo config file for the list included the line reply-to: [EMAIL PROTECTED] then all replies would by defualt go back to the list. While this isn't ALWAYS appropriate, it usually is This particular model falls apart when you have the FreeBSD development model. Reasons: 1) anyone who wants to test -CURRENT can, thus it doesn't fit typical expectation of alpha Although depending on your circle of friends, it is frequnetly possible to get alpha-level stuff. More so from some places than others. However, according the handbook, FreeBSD-CURRENT is, quite literally, nothing more than a daily snapshot of the working sources for FreeBSD. and FreeBSD-CURRENT is made generally available for 3 primary interest groups: 1.Members of the FreeBSD group who are actively working on some part of the source tree and for whom keeping ``current'' is an absolute requirement. 2.Members of the FreeBSD group who are active testers, willing to spend time working through problems in order to ensure that FreeBSD-CURRENT remains as sane as possible. These are also people who wish to make topical suggestions on changes and the general direction of FreeBSD. 3.Peripheral members of the FreeBSD (or some other) group who merely wish to keep an eye on things and use the current sources for reference purposes (e.g. for reading, not running). These people also make the occasional comment or contribute code. Item 1 is clearly developers, and thus traditionally falls under alpha any way you slice it. Number 2 is perhaps more of a stretch, but even alpha testing implies that some testing is done. Opening up the alpha test to more people doesn't necessarily make it not an alpha test, it simply makes the results more accurate. The more mistakes/bugs/problems you can catch before the beta-test stage, the less problems you will have in beta. The less beta trouble you have, the quicker you can release a product. 2) the developers are generally also the users I don't necessarily see the relevance of that to testing. If anything, it means the tests will be somewhat more thorough, but again, when the developer is the user, the user will use the product as intended, and may never break something. When an end-user is the user, who doesn't know what the underlying data structures are, if the program isn't smart enough to compensate for a stupid user, the user is going to make the program crash. Again, I would point out that in many cases, yes, this is simple user-error, and should not necessarily be the job of the developer to fix stupid users (as my brother-in-law, a programmer, used to call those errors User Headspace Error). 3) The -STABLE branch is not *intended* to be for testing purposed only. It is *intended* to be a useable product. In the commercial world, a beta is NOT INTENDED for regular use, but for testing only. Thus, renaming the -STABLE branch would be a misnomer. I don't necessarily recommend renaming things (especially when the current (no pun intended) naming scheme works fine for most people) I think the perception should perhaps be clarified becuase -stable isn't nearly as stable as one would understand from either the handbook pages or the name. The simplest solution would be to equate -current with alpha code and stable with beta Of course, if you assume that STABLE is BETA level code, then you can expect some glitches, and sometimes things WILL slip through the cracks and cause major headaches...but *in general* you should have fairly stable code, with a few bugs in it. You EXPECT (or SHOULD EXPECT) there to be bugs in itthat's part of the development effort. No, according the the handbook, you should not *expect* there to be bugs in -STABLE, You should be wary, as the handbook warns you, but my experience with -STABLE over the last two years is that it's generally pretty reliable. The handbook also states that you should subscribe to the stable mailing list if you intend to track -STABLE, so anyone following the hanbook is going to be well informed when breakage occurs. hmm...maybe we are reading different versions of the handbook? FreeBSD-STABLE is our development branch for a more low-key and conservative set of changes intended for our next mainstream release. Any changes to this branch will have debuted in FreeBSD-CURRENT first, helping to reduce (but not eliminate) the chance that the changes will cause problems (from the online handbook) note the but not eliminate phrase. There is the expectation that the code should be relatively bug free (since it has been through one set of tests already) but one set of testing isn't necessarily enough. There *will* be problems (as you pointed
Re: Staying *really stable* in FreeBSD
On Tue, 26 Jun 2001, Nik Clayton wrote: I've rewritten section 19.2.2.1 and 19.2.2.2 at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html Do people think this gets the point across any better? Yep! It's now abundantly clear. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Staying *really stable* in FreeBSD
On Wed, 27 Jun 2001, Bill Moran wrote: In a company, alpha testing is done by the developers or other employees of the company, Once Upon A Time this was true, but no longer. Viz. Microsoft's Technology Preview editions of various pieces of software. Due to lengthening development cycles, companies feel compelled to issue some pretty raw code into the public eye, just to show that they're actually doing something. The mindshare game I guess. Anyway, code never gets out of the beta stage. ;-) Oh, and could you please wrap your lines? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Staying *really stable* in FreeBSD
On Wednesday, June 27, 2001 3:14 PM, Mike Porter [SMTP:[EMAIL PROTECTED]] wrote: On Wednesday 27 June 2001 09:44, Bill Moran wrote: Is there a reason why you took this off the list? my mistake (or my mailer's depending on how you look at it). If the majordomo config file for the list included the line reply-to: [EMAIL PROTECTED] then all replies would by defualt go back to the list. While this isn't ALWAYS appropriate, it usually is No problem. I expected as such ... looking back, I had intended that question to mean Should I not be posting to -STABLE but then I *did* post to -STABLE so it was pretty silly to bring it up at all ... snipped much reasonable and well-though discussion, because the last paragraph of your reply makes a point the nullifies most of the argument I agree, but I think that putting things in terms people can understand is also important, and mentioning something along the lines of the above paragraph might help some people better undrstand the relationship between -current, -stable, and -release. To take all the specifics out and state my opinion in one general comment. The statement you make above is the exact reason I don't think that beta is a good name. Folks are used to seeing the label beta on some sort of static release that they can test and compare (beta1, beta2, etc) Whereas -STABLE is a constantly moving target. If you looked into it, there would be what? 20,000 possible versions of 4.3-STABLE so far? And you can grab any one of those versions if you want (like if you know a certain feature appeared after a certain date, but a certain bug didn't appear till a certain date) This is the biggest divergence from a beta type software that I see. On the other hand.I seem to recall the initial post in this sub-thread was something like if we are taking votes 1) I don't think we really are taking votes and 2) even if we were, I think the majority by their failure to chime in is indicating their general pleasure with the status quo. True. Considering the core team hasn't asked for a vote, I assume that they either know what they want to do, or they plan to discuss it amoung themselves. I will agree that -STABLE is somewhat misleading. If we had a single word that meant conservative development, that would be the perfect label for that branch. I still think that beta is not that word, but as you put it, there seems to be general pleasure with the status quo. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Staying *really stable* in FreeBSD
On Wednesday, June 27, 2001 5:30 PM, Juha Saarinen [SMTP:[EMAIL PROTECTED]] wrote: On Wed, 27 Jun 2001, Bill Moran wrote: In a company, alpha testing is done by the developers or other employees of the company, Once Upon A Time this was true, but no longer. Viz. Microsoft's Technology Preview editions of various pieces of software. Due to lengthening development cycles, companies feel compelled to issue some pretty raw code into the public eye, just to show that they're actually doing something. The mindshare game I guess. True, but I guess it still just seems to me that alpha is a closed-source kinda word that doesn't fit in with any open-source type of development. Might just be my perception of the whole thing. Anyway, code never gets out of the beta stage. ;-) I don't know. I mean, beta says to me, we, as developers, can't find any problems, but this hasn't been tested in the real world yet. Whereas a release tag says we've tested this under real world conditions and have not found any problems I see where you're coming from with that statement, though. Especially open-source development, which is always under scrutiny for the purpose of improvement. Oh, and could you please wrap your lines? Yeah ... I just realized that the only way to keep Outlook from mangling lines is to manually wrap. I'm working on site this week, far away from my comfortable FreeBSD desktop workstation :-( so I'm stuck with Outlook. I think I'll install mutt on one of the servers here and use it to get my email via ssh ... :-) Don't tell my boss. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Staying *really stable* in FreeBSD
On Wed, Jun 27, 2001 at 13:13 -0600, Mike Porter wrote: On Wednesday 27 June 2001 09:44, Bill Moran wrote: Is there a reason why you took this off the list? my mistake (or my mailer's depending on how you look at it). If the majordomo config file for the list included the line reply-to: [EMAIL PROTECTED] then all replies would by defualt go back to the list. While this isn't ALWAYS appropriate, it usually is Argh, no! Not again, please! Just do *one* search for reply-to and harmful in your favourite search engine and make sure you understand what's broken about this dumb down approach. This has been discussed recently (besides coming up again and again without getting any better by doing so). virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s get gpg key [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Staying *really stable* in FreeBSD
This looks really good! Ship that baby! :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Staying *really stable* in FreeBSD
JW I react rather badly to some of your comments concerning the usability of JW FreeBSD. Our goal *should* be a simple and turnkey system, or at the least, SH That would be a RELEASE. They are usually pretty good at being just that IMHO. No, usability follows from design and functionality. That means thinking about it at the release canidate stage is to late. JW I mean better equip the commiters. Such things are possible, and done every JW day in the software world. Many aspects of code review and regression JW testing can be automated. The time of volenteers in the committer group is SH The time it takes to set up good automated regression testing is amazing, it is also a good way to perpetuate bugs. More importantly such testing is nearly useless in the face of new functionality, or timing and compatability issues. The general quality of -stable indicates that pre commit testing is done rather better than average in the industry. Remember that in most of the industry the only people who see software at the equivalent of -stable are *developers*. It is not unusual for software to emerge from several weeks of regression, integration, acceptance and soak testing into the field only to get bug reports in the first week of real use. It's true that these methods are not siliver bullets. The methodology religion folks (I guess XP is the newest one of those) tend to fall into that hope. But reguardless, some simple things do work. For example, structuring peer review and tracking repeated mistakes of practice. This has nothing to do with a smart automated system of any sort, but does help keep track of things for developers, especially helping to codify the expierence of the senior developers for the benifit of all. JW Again, what I see as the problem is -stable isn't as stable as some people SH Frankly you are dreaming if you think -stable can get much better without slowing down a lot, at which point you hit the security fix branch which never contains any feature that hasn't survived a Beta test. Hammer on the Beta and RC phases to improve the quality of this. Sure I'm dreaming, but it's certainly not an imposible dream. Stability comes from design. It's true that some means of achieving that goal have performance implications, but for the most part, it's completely independent of the speed of the code. And as far as that goes, I'll take *any* improvement in stability over speed any day. I help build rally cars. 90% of winning in rally is about reliability and useability: keeping things running smoothly and consistantly till the end. There are plenty of hotshots out there with very impressive and fast cars. But when you roll it off the road or blow the engine because you're a boost junky, all you do is let someone with half the horsepower and consistant performance walk all over you in the championship. Anyhow, I run -stable, and for the most part, haven't had many problems. But I think there perhaps should be more emphasis on keeping the standards of -stable a bit higher. jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Staying *really stable* in FreeBSD
JK All of your problems can be traced back to old hardware or inexperience with the latest thinking in BSD land. Because you have not upgraded your 2.x system, you are essentially stuck. Either get newer hardware to work with or go through the upgrade based on your subscription disks. While that's true in the particular it's still useless advice, and what you're missing is his intent: ie he *shouldn't* be stuck and forced to build a fresh system, and that we should do something to ensure that doesn't happen again. JK The tracking of stable is not for everyone. Noone *needs* to track stable. JK What we need is an apt-get-like upgrade path for security fixes that solves the problem of people tracking one version of stable or another. Remove the necessity of recompiling from source and we remove almost all reasons for people to complain about the stableness of stable just because they ran into a minor problem of timing WRT cvsup and updates to the source tree. That's what -stable is SUPPOSED to be, incremental stable bugfixes and functionality updates from the most recent release. Also, there are many advantages to building from source rather than running genericly compiled i386 binaries. I personally love letting gcc be as agressive about optimising to my architecture as possible. On top of that is the standard kernal tuning argument and advantages. I also disagree with your comments re make and the difficulty of rebuilding a system. I am completely new to the unix developement world and make. I'm completely new to freebsd. I was able to rebuild my system without incident following 5 lines of instructions from someone on this list. Obviously this *isn't* rocket science, and aside from eyeballing things in mergemaster, we shouldn't sit back on our haunches and perpetuate the idea that building from -stable is something only for the freebsd cognizati elite. We are not talking about what *is*, we are exploring what we feel things *should* be. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Staying *really stable* in FreeBSD
I think it's become clear in this discussion that some people reguard -stable as the secure, regularly updated moving release canidate. Other people view -stable as a just stable enough branch for developers to coordinate building new functionality. If the 2nd view is the official one, then a new branch should be started that has the first purpose in mind. Weither you like it or not, a great many users are simply going to insist that they have some way of updating the system at a days notice of security or stability issues imbetween releases. In my own expierences working in the software world (CRM, not anything systems related) releasing new functionality often in small doses, basicly as often as your clients IT staff can stomach dealing with, absolutely obliterates any other approach. Changes in idiology, functionality or configuration are small, delt with quickly, and the feedback loop between request/response and actual implimentation shorts to mere weeks. Everyone ends up much happyer. I was under the understanding, gleaned from the handbook and from some people here, that -stable was the place for this sort of mentality. If it's not, then IMHO, we need a place for it. As anicdotal evidence, I used debian quite a bit a few years back. There certainly was no problem staying with the stable branch there. The OpenBSD team also seems to show it's possible to maintain a stable moving codebase as well. Is it actually any individuals role to oversee the stability of stable? Or is it left to each individual committer who's checked out certain tasks to judge if his code is safe enough to move from -current to -stable? Whole holds the vision of common practices and evangalises them to the rest of the developers? Who ensures (by review) that a mistake of practice only happens once? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Staying *really stable* in FreeBSD
Mike Porter writes: [Lots of rambling ideas ...] First of all Mike, quite an interesting post. Unfortuantely, either the author of the book didn't understand or didn't explain the CMM well enough for you to be able to use it. I have worked as a Software Quality Engineer (really doing Quality, not being a glorfied tester as the software industry seems to call anyone who runs a test a quality engineer, just like anyone who has written a line of code gets to call themselves a software engineer...) and I have helped organizations achieve CMM Level 3 and above. If you look at the actual CMM, you could argue that the general FreeBSD process qualifies for Level 2, given a little more work on the Project Management and Configuration Management fronts. The main things missing is good design documentation and real attention to CM issues. However, I do not think it is possible for any open source volunteer effort to get better than Level 2. It requires really dedicated resources in the upper management areas that just won't happen outside of a corporate context. Also, when you start throwing process ideas around a group like this, you might not be received very well... I suggest you go read the various XP books (eXtreme Programming). They are small and easy to digest and are much more applicable to this environment (except for the pair programming part...) /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Staying *really stable* in FreeBSD
On Fri, Jun 22, 2001 at 11:54:10PM -0400, Kevin Way wrote: cvsup works fine over dialup, and not unacceptably slowly either. I cvsup the whole thing, maintaining my own local copy of the entire repository. Source, ports, doc, gnats, www. No refuse files at all (not got round to it). I normally use a 64K ISDN connection to my ISP, and the cvsup server is fairly close to them. Line utilisation is close to 100% only when rsyncing big files in the www collection (book.html etc). Most of the time line utilisation is very much less. Elapsed time is bearable. Of course, if you start with nothing, the first cvsup takes a while - 7 hours with two channels (128K) going, close to flat out as I recall. A satisfied dialup cvsup user, Me too. I started with CTM, moved to checking out stable from a cvsup mirror, and on to having my own repository. Its all a bit heavy on disk space, but that is fairly plentiful nowadays. Aside: my first UNIX box ran SCO ODT, with 120 MB of disk and 8 MB of memory. Definitely too little disk (8-( -- Adrian Wontroba To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Staying *really stable* in FreeBSD
FreeBSD Admin [EMAIL PROTECTED] types: I haven't posting anything in some time, so I'm making up for it now with this tome. 8-) It says nothing important and means nothing, so skip as you like. You do have some very good points, and some of them are being addressed already. Don't think that the computer industry doesn't look at what goes on at the FreeBSD jamboree. FreeBSD could be the next Linux, (stop booing) in terms of gaining a much larger industry following since we all know it totally trashes Linux. But and it's a big BUT, the industry PERCEPTION of the FreeBSD community, it's response to security problems, it's ability to recognize problems with stability, and reliability, seems to matter more than what the reality is. This is all very true, but you have to consider what the goal of the project - or rather, the people working on it - is. While I don't speak for them, as far as I'm concerned getting lots of people to use FreeBSD is less important than continuing to provide a quality computing platform. One of the advantages of open source is that the developers can ignore the popularity contest of the market, and concentrate on quality. Not that I wouldn't like FreeBSD to be the most popular platform around, but if it has to become Windows - or even Linux - to do so, it clearly isn't worth it. I've seen enough tools go sour in pursuit of market share that I'd rather not see a single change that sacrifices quality for market share. I use and maintain AIX and HP-UX systems. I very much love FreeBSD --- that is, except for this maintenance nightmare. Because it's so hard to pinpoint an exact microsecond in time when STABLE is really almost/nearly/ stable, I'm still running a 2.2.8 system. Since there's also no decent way to upgrade, I've been waiting for the time to built a new system and switch over. Except, that time never seems to come. I finally stopped my subscription to the CD. I have a stack of them from 2.2.5 all the way up to 3.4 (3.5?). Note that the section heading of the handbook is The Cutting Edge. I don't track current on anything in any kind of production, and I don't track stable on anything even remotely critical. I've maintained AIX systems, but SunOS, Solaris and Ultrix are what I normally deal with. The process of upgrading those systems is no easier than ugprading a FreeBSD system that's through the subscriptions. FreeBSD doesn't have anything like the binary patches available for those systems, and I've complained about that lack myself. Then again, none of them have anything like tracking stable - much less current - and I miss that when dealing with those systems. I started once before with the 3.x branch, building another system. Oops. Suddenly all the device and partition and slice names changed. I just didn't have a whole weekend to devote to this, so it got abandoned. There's a reason for such things. If you really want, I can explain it. I will note that Solaris does - well, once did, as they fixed it - worse. It renumbered the disk drives after an upgrade, which left one system trying to mount a raw Ingres partition as /usr. I need a relatively painless way to keep my system current with vital security patches, and fix broken subsystems, without having a Ph.D. in FreeBSD, or needing to spend 20 hours of my weekend figuring out what to do. I agree, that would be really nice. I do it by tracking stable on a production machine that's not critical. I'm very careful about it - which means it takes time. Mission critical machines generally run softare off the CDs. I watch the security list, and when a bug shows up in software that they are running, I'll skip updating the production system tracking stable, and ugprade the effected machines from the source tree that machine has been running for at least a week. With 4.3, there's a new branch to track - RELENG_4_3 - that contains nothing but security fixes. I'm looking forward to giving it a try. There are apparently also binary patches built from RELENG_4_3, which I may well use instead. How can I patch my system from a STABLE branch that doesn't have specific builds that I can choose from? My druthers would be to stay back a few weeks and then pick up something that's had the problems know up to that time, worked out. Sort of like doing a bi-weekly code freeze and new build. But I think that means propagating the fixes to the fixes back to each build along with other problems. There must be a way something like this could be done to increase the stability and reliability of the product. That's pretty much what RELENG_4_3 addresses. It doesn't make the job of upgrading from one RELEASE to another any easier; after all, you'll be upgrading from RELEASE X.Y + bug fixes - whether they are applied as binary patches or as a source build - to RELEASE X.(Y+1) in either case. Without making it insanely difficult for hundreds of wonderful volunteers, shirley (8-)
Re: Staying *really stable* in FreeBSD
On Sun, Jun 24, 2001 at 02:45:24AM +0200, Michael Nottebrock wrote: snip You make some very good points. For you, like 99% of Linux users, you are better off never attempting to cvsup or to track stable. [...] I just like to say that my experience with tracking stable is quite positive. I installed FreeBSD 4.2-Release with the boot floppies and a snip openssh clients like the 2.9pl1 in Linux Mandrake) doing a Release-2-Stable and a Stable-2-Stable upgrade from source has been a breeze, thanks to the guidance of /usr/src/UPDATING and the FreeBSD Handbook (and the FAQ for explaining kern_securelevel and it's impact on file flags). All this updating from source at least never left me without a root filesystem when booting a new kernel (as did Linux Mandrake 7.2 I've never had a problem tracking and building stable resulting in an unbootable or generally unusable system. There was the one and only time I tried making installworld in the recommended way, via single-user init level and the system spontaneously rebooted. But, otherwise, no problems at all. Even for a period of time when I was cvsuping and making the world every day... which ended immediately after I got that month's electricity bill. Good god damn, I'm obscenely lucky, aren't I. Wait a minute... I SEE NO SUPER MODEL SEX KITTEN ON MY BED!@#$ It must be FreeBSD, not my luck. snip kernel). IMHO, the FreeBSD stable sourcetree and also the ports packages collection are in such a good shape that they don't need to fear any comparison with rpm or deb based Linux distributions. Hey, even Windows NT When a port doesn't work for me, I cvsup the ports tree and it's fixed or someone on stable has said they're fixing the problem presently and it's fine the next day. It's all a wonderful dream. Better than kittens or ice cream or puppies or rainbows. 2000 boxen have been reported to break after installing a Service Pack, after all. Windows service packs are on the same level as medieval alchemy. 600 years from now, science will find a way to make windows secure and stable. Not only that, but cloning will be perfected and posterity won't be left with the horrible prospect of a world without Carrot Top and Rob Schneider. snip -- disclaimer: vodka. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Staying *really stable* in FreeBSD
On Sun, 24 Jun 2001 12:00:59 +1200 Juha Saarinen [EMAIL PROTECTED] wrote: JS :: The tracking of stable is not for everyone. Noone *needs* to track JS :: stable. JS JS Well, that isn't what the Handbook says: JS JS 19.2.2.2. Who needs FreeBSD-STABLE? JS If you are a commercial user or someone who puts maximum stability of JS their FreeBSD system before all other concerns, you should consider Emphasis on this word _ JS Reading that para (plus the ones before that), effectively tells you JS that -STABLE is what you should use for err maximum stability. You JS get the bugfixes and security fixes that aren't in -RELEASE. Reading further will show that this comes with an *inevitable* price namely that you have to read -stable and be sensible about it. JS So... you need to track -STABLE, right? JS :: the peculiar make used by FreeBSD. What we need is an apt-get-like JS :: upgrade path for security fixes that solves the problem of people The new security fix only branch should serve this need nicely. Now -stable is only needed for those who want/need to track bug fixes and new features. -- Directable Mirrors - A Better Way To Focus The Sun http://www.best.com/~sohara To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Staying *really stable* in FreeBSD
Ok, last try. I'm not trying to push responsibility off on anyone. There will be in infinitesmal amount of work involved. The tag points to the RELENG_X_Y tag with the highest X primarily and the highest Y secondarily. That's it. No more. If someone has decided to create a new RELENG_X_Y then no one makes a decision to move the magic tag. There is an algorithm. That's why it is too simple to waste time on. I've seen a lot of traffic from people who don't like the instability of STABLE. Then someone mentioned tracking RELENG_4_3 then moving to RELENG_4_4_RELEASE, then to RELENG_4_4. I thought this sounded like nice compromise of features vs stability. Then I thought, wouldn't it be nice if it was automatic? If a computer can do it, I don't want to waste my time on it. Hence the email. It is just another way for people to track sources in some way they are comfortable with. The delta of changes is not the issue, it is their *stability*. If people don't want to track this tag, then they don't have to. I don't track - -CURRENT, but I don't think it shouldn't be allowed to exist. I thought that if two people wanted something like this, then more might, and it might prevent some tracking problems. No version change confusion: I'm tracking MAGIC_VERSION and uname -a shows that. No - -RC/BETA/etc confusion. And, hey, it compiles. And works. No need to send mail to find out how to fix it. The fact that most people talk about -STABLE unqualified with a version number and that the name of this list is freebsd-stable, again unqualified with a version number, seems to imply that people think in terms of a single stable stream of changes to FreeBSD. I think it would be nice to tag that stream of stable changes with a single tag. Again, people would be free to ignore it and track any RELENG_X_Y they choose, or any other tag they choose. The only issue I see is when a RELENG_X_Y appears after an RELENG_X+1_Z has begun. My choice is highest X wins. Since the RELENG_X_Y branches are considered most stable, then RELENG_X_Y must be as *stable* as RELENG_X+1_Z, and the tie breaker for me is more features and so a move the the X+1 version. A personal preference, I admit. Like I said before, I would be more than happy to do it myself, if I had programmatic access to all tags. Here's an AI program to make the decision: #!/usr/bin/env perl @sv = sort(@ARGV); print @sv[$#sv], \n; exit(0) Once again, this is why it is too trivial to type so much about. This may be a bad and stupid idea, but if so, please attack it from a position of understanding what it is, not something else. And regardless, this is a stream *I* would track, so it is not 100% wrong. regards, davep (random, but appropriate, sig:) - -- Howe's Law: Everyone has a scheme that will not work. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Staying *really stable* in FreeBSD
Dmitry Karasik [EMAIL PROTECTED] types: On 21 Jun 01 at 16:45, Jason (Jason Watkins) wrote: Jason Don't camoflage one problem by providing a solution to Jason another. What you're really worried about is how stable -stable Jason is. Address that, and things will be better than managing: Jason -its_not_stable_but_we_pretend -stable -yet_more_stable Jason -so_stable_its_more_stale_than_the_cheesewiz_in_my_house Well, instead of criticizing the only decent proposition in the thread you all people could invent something that works. But no one wants to, that's the point. If it were a decent proposition, it wouldn't be drawing criticism. What we have is a system that works, in the form of CURRENT, STABLE and RELEASE. We also have a new facility in the form of a branch that inludes only security fixes from STABLE - something I'm going to call RELENG. RELENG was introduced with the previous release, and we now have a proposition designed to work around the problem of having to edit the supfile to change to a new branch after a release. This is exactly the way things have worked with STABLE, and I've never seen anyone claim that that was a problem. Since this case has never happened, any problems are hypothetical. The relevant experience with FreeBSD is that: 1) Editing the supfile is trivial, and seldom causes problems. 2) Tracking STABLE at reasonable intervals is straightforward, and seldom causes problems. 3) Jumps of a release are slightly more complicated, sometimes cause problems, and should be handled with care. 4) Jumps across versions are a major PITA, and almost always have to be given special treatment. RELENG is an attempt to make life easier for people who don't want to upgrade their system, but do want to get security fixes. Given that goal and the relevant experience, RELENG seems to be a good solution. It may not be, but we really need some evidence before making such a decision. So we have a proposition that moves the work from people who want to track stable in a manner resembling the punctuated equilibrium theory of evolution to the release engineer - who is a volunteer - to solve a problem that has never been observed in the wild. Before doing any work to fix this problem, it would be nice to have some evidence that this problem exists, and to have more experience with the process of taking a system from one RELENG branch to the next one. If the problem is instead that STABLE isn't STABLE enough and RELENG doesn't move fast enough - though evidence for the latter would also seem to be in short supply - then one of those two problems should be attacked, rather than trying to automate something that experience shows doesn't automate well. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Staying *really stable* in FreeBSD
Valentin == Valentin Nechayev [EMAIL PROTECTED] writes: Laziness is compatible with anything when it means not doing any unnecessary work. It is not a matter of knowing it needs changing, it is a matter of changing it. Any time a procedure and be automated, it should be. It should be one's choice whether or not to use the automation, however. That's why I suggest a new tag rather than redefining an existing one. Why should I: 1) su to root 2) co -l supfile 3) edit supfile (correctly. Small chance of a typo, but non-zero vs 0% when *not* editing the file) 4) ci -u supfile when I can do: nothing. This is easier, and less prone to mistakes. Given these two lists, Occam's razor would, I think, select the zero length list as the simpler one. Regards, davep Valentin Thu, Jun 21, 2001 at 16:20:15, davep (David A. Panariti) Valentin wrote about Re: Staying *really stable* in FreeBSD: How about adding another tag that always refers to the latest RELENG_x_y. Then we (paranoid and lazy types) can just cvsup that tag without needing to change from RELENG_X_Y to RELENG_X_Y+1 and RELENG_X+1_0. Valentin Paranoia is hardly compatible with laziness. To upgrade Valentin RELENG_4_3 to RELENG_4_3 you must know that previous version Valentin is now danger. Hence you read at least announce@. If you Valentin read announce@ you can know that new release is published. Valentin Hence, you know that tag should be changed and you have to Valentin prepare for possible problems. Valentin Cut it with Occam's knife. Valentin /netch -- I never fail to convince an audience that the best thing they could do was to go away. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Staying *really stable* in FreeBSD
And this would be different than -stable how? Then we (paranoid and lazy types) can just cvsup that tag without needing to change from RELENG_X_Y to RELENG_X_Y+1 and RELENG_X+1_0. Don't camoflage one problem by providing a solution to another. What you're really worried about is how stable -stable is. Address that, and things will be better than managing: -its_not_stable_but_we_pretend -stable -yet_more_stable -so_stable_its_more_stale_than_the_cheesewiz_in_my_house etc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
