CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3

[Robert Watson]

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