From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 19 00:00:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E6ED106573E for ; Thu, 19 Jan 2012 00:00:39 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mail-iy0-f196.google.com (mail-iy0-f196.google.com [209.85.210.196]) by mx1.freebsd.org (Postfix) with ESMTP id C30638FC23 for ; Thu, 19 Jan 2012 00:00:38 +0000 (UTC) Received: by iagz16 with SMTP id z16so1191658iag.7 for ; Wed, 18 Jan 2012 16:00:38 -0800 (PST) Received: by 10.42.170.3 with SMTP id d3mr18391099icz.7.1326931238104; Wed, 18 Jan 2012 16:00:38 -0800 (PST) Received: from mikmeyer-vm-fedora (dhcp-173-37-11-196.cisco.com. [173.37.11.196]) by mx.google.com with ESMTPS id or2sm35242023igc.5.2012.01.18.16.00.37 (version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 16:00:37 -0800 (PST) Date: Wed, 18 Jan 2012 16:00:03 -0800 From: Mike Meyer To: freebsd-hackers@freebsd.org Message-ID: <20120118160003.4e5ba5c5@mikmeyer-vm-fedora> In-Reply-To: <20120118233931.GL509@over-yonder.net> References: <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org> <4F16A5B8.2080903@FreeBSD.org> <4F1707E6.4020905@FreeBSD.org> <20120118233931.GL509@over-yonder.net> Organization: Meyer Consulting X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Thu, 19 Jan 2012 00:00:39 -0000 On Wed, 18 Jan 2012 17:39:31 -0600 "Matthew D. Fuller" wrote: > Or there's another option, a variant of (1), where we extend the > lifetime of some major release trains, but not all. Every second, or > every third. Then we can have a longer life, without ballooning out > the number of trains being supported. But that has big drawbacks too; > the problems of backporting aren't just the number of branches to port > too, but how far back they are. Backporting from -CURRENT to 9 right > now is almost trivial. Going to 8 isn't too bad for most things. To > 7, it's getting to be a much bigger deal. If 7 were an "extended > support" train, with 2 years of active support left on it, not only > would backporting things get inordinately expensive from accumulated > differences, but they'd get very _risky_ too. They slip from > "backport" into "rewrite for", and now we've seriously compromised the > stability of the branch, undermining our own goals. Let's look at this again. And look at why people want longer term support. In my experience, they want this because they want security updates/bug fixes for production systems. If LTS changes that were limited to that after the normal support period, and restricted to cases where the effort was warranted by the severity of the issue, it would seriously mitigate the backporting issues. Of course, from reading this discussion, it's clear that there are people who want both long term support *and* new features (at least in the form of new device drivers). It may well be that you get to choose any two of: - Software that is very cheap or free. - Software that is supported over long time periods. - Software that gets frequent updates with new features. Given that this is a volunteer-driven effort, the first is pretty much a given, so you can only get one of the other two. Unless you're willing to lose the first by maintaining your own releases as others have suggested/described.