Date: Tue, 17 Jan 2012 15:50:54 +0400 From: Roman Kurakin <rik@inse.ru> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, WBentley@FutureCIS.com, William Bentley <William@FutureCIS.com> Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <4F15609E.5080405@inse.ru> In-Reply-To: <alpine.BSF.2.00.1201181034580.51158@fledge.watson.org> References: <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org> <alpine.BSF.2.00.1201181034580.51158@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > 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. It looks like Intel's development model. They have two teams. One works on new processor, while the second do upgrade of the previous one. On next turn the last one start the new processor and the first one does. I think it is great model. [...]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F15609E.5080405>