From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 19 07:24:27 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 1DA4D106566C; Thu, 19 Jan 2012 07:24:27 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id F25D28FC0C; Thu, 19 Jan 2012 07:24:25 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q0J6sjpa075969; Thu, 19 Jan 2012 06:54:45 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id q5zbqjcrtn98mru5vs9isg3nei; Thu, 19 Jan 2012 06:54:45 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Wed, 18 Jan 2012 22:54:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <570E1AEB-F0C5-4286-BF10-56D509D33473@kientzle.com> References: <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org> To: Robert Watson X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-hackers@FreeBSD.org, WBentley@FutureCIS.com, Julian Elischer , William Bentley 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 07:24:27 -0000 On Jan 18, 2012, at 2:44 AM, Robert Watson wrote: >=20 > ... perhaps what is really called for is breaking out our .0 release = engineering entirely from .x engineering, with freebsd-update being in = the latter. This is a great idea! In particular, it would allow more people to be involved. There's a practical limit to the number of people that can be involved in any single release process; having multiple groups handling separate releases (for example, we might have a group working just on 8-STABLE releases, so that 8.3, 8.4, etc, weren't competing for resources with the more complex 9.0 release). Tim