From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 18 20:27:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id C40F11065672 for ; Wed, 18 Jan 2012 20:27:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0EC19150B69; Wed, 18 Jan 2012 20:27:10 +0000 (UTC) Message-ID: <4F172B1E.30401@FreeBSD.org> Date: Wed, 18 Jan 2012 12:27:10 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: John Kozubik References: <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org> <4F16A5B8.2080903@FreeBSD.org> <4F1707E6.4020905@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 20:27:11 -0000 On 01/18/2012 11:46, John Kozubik wrote: > - mark 9 as the _only_ production release While I understand your motivation, I am not sure this is a workable goal when combined with the goal that others have expressed of longer timelines for the support of a given branch. Speaking from personal experience, once a service is released on a given platform the costs of migration can be significant. And if what I have is working well and only needs the occasional bug/security fix my motivations for migration are near zero. So the tradeoffs then become more frequent major releases to get new features, vs. longer support for a given release branch. Let's take 5 years as a reasonable time period for supporting a branch. Waiting that long between major releases would significantly stifle the ability to add new features that require breaks to the [AK][BP]I. It would also inhibit our ability to do revolutionary architectural changes such as moving to clang as the primary supported compiler. What I've proposed instead is a new major release every 2 1/2 years, where the new release coincides with the EOL of the oldest production release. That way we have a 5-year cycle of support for each major branch, and no more than 2 production branches extant at one time. History tells us that 2 production branches is a goal we can achieve, with the focus shifting more heavily towards only bug/security fixes in the oldest branch after the new production release branch is cut. If we combine that with the ideas that are being put forward about teams that "own" a production branch, and a more frequent stripped-down release process, I think this is a very workable model. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/