From owner-freebsd-arch@FreeBSD.ORG Tue Dec 21 22:28:01 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5388E106564A; Tue, 21 Dec 2010 22:28:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2688FC19; Tue, 21 Dec 2010 22:28:01 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id A000B46B17; Tue, 21 Dec 2010 17:28:00 -0500 (EST) Date: Tue, 21 Dec 2010 22:28:00 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <201012211500.16131.jhb@freebsd.org> Message-ID: References: <201012211500.16131.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mdf@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Schedule for releases X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 22:28:01 -0000 On Tue, 21 Dec 2010, John Baldwin wrote: > I'm not entirely sure what the right answer is, but this is something that > has worried me for a while. I see a few specific tensions to worry about, but they're not new ones. The questions, really, are whether significant downstreams run into the following problems: (1) Is our rate of change too great to allow useful upstreaming? (Regardless of "releases") (2) Is our security support lifetime for -STABLE branches too short to allow major products to be built on them and have the downstream product lifetime largely live within our lifetime? (3) Do old -STABLE branches stagnate too quickly with respect to device driver support such that they can't be used? (4) Are our point releases (.1 -> .2 -> .3) too large for downstreams to roll out as incremental point releases of their own products, extending their lifetimes? (5) Do ports/packages stop supporting a branch before the useful lifetime of a -STABLE-based branch, such that a derived produt has to locally maintain versions of {Apache, ...} rather than rely on project infrastructure? Looking at recent events, it strikes me that (3) is actually the most significant problem from the perspective of many vendors. They'd like new device drivers to keep going back to 7.4, 7.5, and 7.6, perhaps without significant software changes, so that they can keep shipping a product that has to run on new hardware, but doesn't require new OS features otherwise. Our improvements in thinking about KPI have helped there, as well, but there's more to do. I think there's also a potential confusion among some of our downstreams relating to our point releases. As Colin has pointed out, they're really best thought of as "service packs", not OS releases in a recent sense. Anyone building an embedded product/appliance should probably take the perspective that they will align delivery of an initial major release of their product with the .1/.2 of a FreeBSD branch, and that they will then ship occasional OS baseline updates to pick up new device drivers, bug fixes, minor software features, etc, at intervals after that. Looking at 7.x, I'm struck by how much it has slowed down. There's a significant user community, but not a significant developer community. There was a non-trivial discussion of whether a 7.4 should be cut at all, given its potential to product secteam (etc) support commitments for three major branches for an extended period. One thing we could do is better engage our downstream communities into helping to extend the lifetime of -STABLE branches by contributing to driver backports, long-term security maintenance, etc. If (random vendor handwave, no insult to Intel meant) Intel isn't interested in doing the backports of, say, {em, igb, ...} to 7.x, then that needs to be pushed by someone with a product or environment that requires them to be interested. We need to ensure that there are continuing developer communities reflecting the continuance of user communities. Robert