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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
