Date: Wed, 18 Jan 2012 10:44:28 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Julian Elischer <julian@freebsd.org> Cc: freebsd-hackers@freebsd.org, William Bentley <William@FutureCIS.com>, WBentley@FutureCIS.com Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <alpine.BSF.2.00.1201181034580.51158@fledge.watson.org> In-Reply-To: <4F14BAA7.9070707@freebsd.org> References: <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Jan 2012, Julian Elischer wrote: > On 1/16/12 3:32 PM, William Bentley wrote: >> I also echo John's sentiments here. Very excellent points made here. Thank >> you for voicing your opinion. I was beginning to think I was the only one >> who felt this way. > [...] > >> We seem to have lost our way around the release of FreeBSD 7. I am all in >> favor of new features but not at the risk of stability and proper life >> cycle management. >> >> Are me and John the only people that feel this way or are we among the >> minority? > > It pretty much boils down to one thing.. man power.. I disagree. Resourcing is an issue, but it is not *the* issue. The real issue here is a failure by the release engineering team (which includes me) to concurrently perform major and minor releases. Given that minor releases run like clockwork in most cases, this is disappointing. In the past, there have been a lot of good technical and structural obstacles to trying to do clockwork releases for both major and minor releases: - Tight synchronisation of the ports and base release schedule means that the base release schedule limits ports productivity. - Long freezes forced on us by poor revision control support for branching. None of these really apply any longer -- and in as much as they do, they should be addressed. In particular, I think there's a growing feeling that ports should be conducting its own releases out of lockstep with the base tree, producing package sets as a primary product at regular intervals regardless of the base release schedule. Likewise, long freezes enforced by expensive branching operation in CVS no longer apply due to use of Subversion -- it's not perfect, but it's workable. There's no way to satisfy everyone with any particular maintenance schedule and release cycle. However, it seems clear that the current model with minor releases spaced at a year is satisfying no one. It's easy to point at a developer<->user divide, but I think that misses the point: most developers are users. A big gap between development branch and shipped features hurts the commercial users of FreeBSD that pay for so much of its development, since it forces them to support diverging local development and shipping products -- ISPs, etc. There is no incentive for year-long gaps in minor releases. My view is therefore that we have a "social" -- which is to say structural -- problem. Regardless of ".0" releases, we should be forcing out minor releases, which are morally similar to "service packs" in the vocabulary of other vendors: device driver improvements, new CPU support, steady of conservative feature development, etc, required to keep older major releases viable on contemporary hardware and with contemporary applications. One known problem is using a single "head" release engineer in steering all releases. I think this is a mistake, as it makes the whole project's release schedule subject to individual unavailability, burnout, etc, as well as increasing the risks associated with low bus factor. I'd like to see us move to a model where new release engineers are mentored in from the developer community for point releases, ensuring that we increase our expertise, share knowledge about release engineering in the broader community, and get new eyes on the process which can lead more readily to process improvements. The role of the "head" release engineer shouldn't be hands-on prodution of every release, but rather, steering of the overall team. I'd like to see this begin with 8.3, drawing a per-release lead from the developer community, and continue with a fixed schedule release of 8.4. Yes, more staffing is needed, but first, what is needed is an improvement in model. On a related note, the security team owns the "freebsd-update" mechanism, largely for historical reasons (Colin wrote it), but this is actually a bit backwards from how you would expect things to run, as we now use freebsd-update for upgrades, which are almost never engineered by the security team. Not sure what the fix is there, but it seems related -- perhaps what is really called for is breaking out our .0 release engineering entirely from .x engineering, with freebsd-update being in the latter. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1201181034580.51158>