From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 22:16:52 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 0D6BB106568F; Sat, 18 Feb 2012 22:16:52 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id DEAB68FC17; Sat, 18 Feb 2012 22:16:51 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 6266756203; Sat, 18 Feb 2012 16:16:51 -0600 (CST) Date: Sat, 18 Feb 2012 16:16:51 -0600 From: Mark Linimon To: freebsd-hackers@freebsd.org Message-ID: <20120218221651.GB1240@lonesome.com> References: <20120119005658.218280@gmx.com> <4F19188A.4090907@herveybayaustralia.com.au> <4F213CEB.4020207@herveybayaustralia.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F213CEB.4020207@herveybayaustralia.com.au> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Sat, 18 Feb 2012 23:20:51 +0000 Cc: linimon@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: Sat, 18 Feb 2012 22:16:52 -0000 On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da Rock wrote: > 1. Incidentally, what exactly does constitute a major release? That point in time where we guarantee that we break a certain degree of backwards compatibility. (Well, that's the key component. Feature- additions ride on top of that.) > 2. Is there a reason to update the numbers so quickly? Yes, so that we don't have to keep supporting backwards compatibility for as long a period (see 1) -- it's a significant burden to maintain. It's necessary to do these as we rework things like network layers for higher performance, rework wireless to work with modern devices, and other high-demand items. > 3. Could a higher bar be set to reach a major release than simply > temporal objectives? Yes. We did that with 5.x, and blew it big-time. The goal of "rewrite the entire system to support SMP in a scalable, reliable fashion" was simply too aggressive. It led to ~5 years between major releases, and by that time the system had changed very dramatically (SMP, suspend/resume, IIRC GEOM, and too many other things to list). It was a huge jump and the learning curve for upgrading was way too large. We lost userbase. Also, keeping 5 years between major releases led to very high developer frustration. Why work on something when it will take 4+ years to even see the light of day? This is why we moved to the time-based releases. 18 months was seen as a compromise between all the various demands. Even so, we are almost exactly at 24 months in practice; see the graphs I updated last month as a result of all the recent discussion: http://people.freebsd.org/~linimon/schedule/ My own view is that 5 years between major releases is not going to happen, due to how painful the 5.x experience was for all concerned. But as I'm not a src committer, I'm not one of the people who will be picking the interval for our major-branch timeline. I just try to graph it as it goes by. mcl