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


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
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: quota deadlock on 6.1-RC1
    ... There are always tradeoffs between stability and features. ... to declaring 5.X "STABLE" until all the major bugs were fixed. ... running freebsd servers around the world will suffer problems because ...
    (freebsd-stable)
  • Re: quota deadlock on 6.1-RC1
    ... FreeBSD already has many great features which we are happy with, but they need to be refined now. ... Yes, new features are important to stay in the game, but they should not arrive at the sacrifice of stability. ... I.e., cleanups of locking models, removal of long-decayed or no longer useful code, finishing up loose ends, etc. Compared to the new feature lists for the 5.x branch, 6.x and 7.x are significantly less agressive. ...
    (freebsd-stable)
  • Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
    ... You talk about feature stability. ... Your view of "stable" meaning "features don't change" is no where near my definition of stable. ... 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 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 ACPI, etc. ...
    (freebsd-stable)
  • Re: TCP SACK backport to -STABLE
    ... > with the other operating systems I can use, ... > required to run the latest and greatest features in production. ... > commitments to stability and POLA that are so much a part of FreeBSD. ...
    (freebsd-net)
  • Re: quota deadlock on 6.1-RC1
    ... The developers work for free. ... There are always tradeoffs between stability and features. ... to declaring 5.X "STABLE" until all the major bugs were fixed. ...
    (freebsd-stable)
Loading