Date: Mon, 25 Jun 2001 13:47:37 -0700 From: "Jason Watkins" <jwatkins@firstplan.com> To: "Steve O'Hara-Smith" <steveo@eircom.net> Cc: <joe@zircon.seattle.wa.us>, <stable@FreeBSD.ORG> Subject: RE: Staying *really stable* in FreeBSD Message-ID: <JBEOKPCEMKJLMJAKBECCMEPLDBAA.jwatkins@firstplan.com> In-Reply-To: <20010623103557.547f67c5.steveo@eircom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?JBEOKPCEMKJLMJAKBECCMEPLDBAA.jwatkins>