Date: Sun, 8 Jun 2008 23:13:35 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Andy Kosela <andy.kosela@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: <20080608230037.F84920@fledge.watson.org> In-Reply-To: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> References: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080608230037.F84920>