From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 17 23:59:55 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 88EAC106564A for ; Tue, 17 Jan 2012 23:59:55 +0000 (UTC) (envelope-from john@kozubik.com) Received: from kozubik.com (kozubik.com [216.218.240.130]) by mx1.freebsd.org (Postfix) with ESMTP id 71F398FC0C for ; Tue, 17 Jan 2012 23:59:55 +0000 (UTC) Received: from kozubik.com (localhost [127.0.0.1]) by kozubik.com (8.14.3/8.14.3) with ESMTP id q0HNxrY2049177; Tue, 17 Jan 2012 15:59:53 -0800 (PST) (envelope-from john@kozubik.com) Received: from localhost (john@localhost) by kozubik.com (8.14.3/8.14.3/Submit) with ESMTP id q0HNxmBV049174; Tue, 17 Jan 2012 15:59:48 -0800 (PST) (envelope-from john@kozubik.com) Date: Tue, 17 Jan 2012 15:59:48 -0800 (PST) From: John Kozubik To: Doug Barton In-Reply-To: <4F16094E.2080108@FreeBSD.org> Message-ID: References: <4F16094E.2080108@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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: Tue, 17 Jan 2012 23:59:55 -0000 Hi Doug, Thanks a lot for these comments and insight - response below... On Tue, 17 Jan 2012, Doug Barton wrote: > I tried to make the point back in June that there was no reason to cut > 9.0-RELEASE yet because we don't have solid support for clang in either > the base, or ports (amongst several other reasons) and that the delay > for getting that working would be a great "excuse" for slipping the > support schedule for 8 so that we could release 9.0 not-too-long before > 7 was about to go EOL, and make the 8/9/10 release schedules fit the > new, (hopefully) more rational model. Perhaps we can reconsider that > idea for 10.0. Just previously in this thread, I suggested the following: You could progress 8.x along its current trajectory, possibly building 8.4 a year or so from now and then be done with it, and then that would be the last short/unfocused release. Then you postpone 10.0-RELEASE until January 2017. Instead of having a legacy branch and two production branches, you would have legacy (8) production (9) and ... nothing. Or if you need to have it out there, 10 is the development branch. Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15 at the end of the cycle. I wonder if this is too aggressive in that direction, or if this would be a decent balance ?