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

[Robert Watson]

On Sun, 8 Jun 2008, Andy Kosela 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) On the one side 
> we got people (let's call them developers or computer scientists) who are 
> more interested in development than stabilization of the existing code base. 
> It's natural for them to think more about new features, researching new 
> ideas and implementing them. It resembles an academic project, research 
> project.
...
> On the other hand though, there is a trend which focuses on maximum long 
> term stabilization of the code base. Usually we see this trend in high end 
> commercial companies serving the needs of mission critical businesses where 
> even a minute of downtime can cause loss of thousands of dollars or even 
> loss of lives of people (imagine stock exchanges, banks, financial & 
> insurance institutions, army and police facilities, hospitals, nuclear 
> plants etc.). Those types of businesses/institutions truly needs a maximum 
> stable operating system. They really do not care about "new features", but 
> they do care about maximum stability of the existing code, security, and 
> nonstop business continuity even in the face of natural disasters.

I think there are some important truths to your observations, but let me 
present a contrarian view:

I think you are presenting a false dichotomy, unnecessarily pitting developers 
and users at odds with respect to the goals of the project.  There are 
definitely points of conflict along these lines, but much of the time the 
reason that people use FreeBSD is precisely because there *is* agreement on 
these points.  There are many FreeBSD developers who work on FreeBSD precisely 
because their employer uses FreeBSD, and hence directly represent interests of 
long-term support, stability, etc.  And indeed, as you observe, these are the 
interests of large web hosts, appliance companies, etc, being required to 
build their products.

We have a highly branched development in order to reflect the varying degrees 
of both investment in and tolerance for different levels of feature 
development vs. stability.  If FreeBSD developers only hung around to do 
adventurous new feature development, we wouldn't have -STABLE branches, 
errata/security branches, freebsd-update, and so on.  Instead, we have a very 
large infrastructure and a lot of developer time invested in those areas, and 
this has been growing over time.

For example, we introduced RELENG_X_Y errata/security branches in the 4.x 
timeframe to better serve communities with a low tolerance for feature change. 
Prior to that time, users had to directly manage patches themselves if they 
wanted to avoid sliding forward on -STABLE.  Likewise, in the mid-5.x 
timeframe, we added Perforce so that developers wanting to work on projects 
with very high levels of instability could do so without disrupting HEAD as 
much, which both improved the pace of development and lead to a more stable 
product by avoiding allowing the HEAD to become extremely unstable.

The recent and rather contentious discussion is not taking place because 
FreeBSD developers feel that, philosophically, longer support timelines for 
releases are undesirable.  Rather, the argument being made is that, given the 
underlying assumption of finite resources already committed to particular 
ends, we should moderate the degree to which we support old releases so that 
we can keep producing new ones.  Don't think that the same trade-offs and hard 
choices don't have to be made in the development HEAD: in the past, we've 
pushed back several major features over time due to concerns about stability 
or availability of developers, which have been far more contentious.

Just a thought... :-)

Robert N M Watson
Computer Laboratory
University of Cambridge