Date: Sun, 8 Jun 2008 23:41:25 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Freddie Cash <fjwcash@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 Message-ID: <20080608233332.R84920@fledge.watson.org> In-Reply-To: <b269bc570806081527g7280992ao6d2df9a22921ee26@mail.gmail.com> References: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> <b269bc570806081527g7280992ao6d2df9a22921ee26@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 8 Jun 2008, Freddie Cash wrote: >>> Define the terms "stable" and "unstable", how you measure said "stability" >>> and "instability", and what you are comparing them against. >> >> This whole discussion is really interesting as it clearly showcases two >> common trends in computing (rapid development vs stability) > > Like I said, you have to define what you mean by "stable" and "unstable" > before the discussion can continue. > > "stable" can mean many things to many people. You talk about feature > stability. Other may talk about "number of open bugs" as being unstable. > Others may talk of API/ABI stability. Other may mean "code that don't crash > a system". > > Your view of "stable" meaning "features don't change" is no where near my > definition of stable (systems that don't crash, and where I can run binaries > from older point releases on newer point releases). I think very few companies that use FreeBSD want it to be like OpenVMS -- otherwise they'd be using OpenVMS. Companies, and users generally, come to FreeBSD not just because they want system stability over time, but also because they expect us to keep producing new (yet mature) features. Sure, they may claim otherwise, but in practice they discover they do want FreeBSD to support the latest rev of an ethernet chipset on a motherboard because the replacement parts they received from their hardware vendor have it, support for larger disk sizes, support for a new POSIX API, being able to boot on systems that require (rather than just support) ACPI, etc. And those changes, perhaps individually incremental, add up to significant changes requiring new releases quite quickly. Again, I wouldn't argue that we couldn't further improve things, but at the same time, we have to recognize that any discussion about "improvement" in a world of finite resources requires a change in the set of trade-offs we accept. This is one reason why such discussions get contention, because one person's easy win from a change becomes another person's loss. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080608233332.R84920>