From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 18 23:39:33 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 7A6251065670 for ; Wed, 18 Jan 2012 23:39:33 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 428A28FC0C for ; Wed, 18 Jan 2012 23:39:32 +0000 (UTC) Received: from draco.over-yonder.net (c-174-50-4-38.hsd1.ms.comcast.net [174.50.4.38]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 1A6CA37B4E4; Wed, 18 Jan 2012 17:39:32 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 5DAF41774D; Wed, 18 Jan 2012 17:39:31 -0600 (CST) Date: Wed, 18 Jan 2012 17:39:31 -0600 From: "Matthew D. Fuller" To: Mark Felder Message-ID: <20120118233931.GL509@over-yonder.net> References: <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org> <4F16A5B8.2080903@FreeBSD.org> <4F1707E6.4020905@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.3 at thyme.infocus-llc.com X-Virus-Status: Clean 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: Wed, 18 Jan 2012 23:39:33 -0000 On Wed, Jan 18, 2012 at 02:20:56PM -0600 I heard the voice of Mark Felder, and lo! it spake thus: > On Wed, 18 Jan 2012 13:46:45 -0600, John Kozubik wrote: > > This is nice because no upheaval needs to happen with 7 and 8, and > > interested developers do not get kneecapped vis a vis 9 - they can > > just keep going where they were going with it, and the only real > > change is that 10 is pushed out a long ways, and people[1] get to > > really sink their teeth into 9. > > > > What are the policies for changes though? Are we stuck with 9.0's > feature set for 5 years? Will we have to wait 5 years to get a > stable release of FreeBSD with KMS/GEM? That work is unfinished and > didn't make 9.0; it's also a huge changeset. How will things like > this be dealt with? Five years is a long time for the next stable > release if we have a policy to not import major changes from > -CURRENT. It would be devastating to so many users. This is where the problem comes in. As I read it, John's problem in a sentence is "I just got onto 8.x, and it's already shutting down!" If the problem is "stable trains don't live long enough", why, the solution's simple; make stable trains live longer! The problem is, there are unpleasant tradeoffs every direction we try to go with that. We can: 1) Just make each one live longer. Of course, that means that pretty soon we're maintaining 3 and 4 -STABLE branches all the time. Yeah... "maintaining" is sure to be an overstatement in that case. Even if we had massively more manpower, the project management complexity would still eat us alive. This is just a non-starter. 2) Wait longer between making new ones. This is what John is suggesting above, but it has two related huge drawbacks. The a) As Mark said, is that it means any significant new features or architectures come out a couple years after they're already obsolete. To pick one example, from 8->9 we have the new eventtimers stuff, which drastically reduces the number of clock interrupts. As we get 4 and 8 and 16 and higher core counts becoming common, that gets very important, as servicing 32k interrupts/second while completely idle is really bad for system efficiency. If we pushed 9 out to 2 years or so from now, we're telling people "sure, just eat the overhead until then". Whoops. b) The other big drawback is as I've said in other mails; it turns every major release into a giant watershed of everything changing, which makes upgrading systems across it a *HUGE* amount of work, and *VERY* risky. Again, this had an impact in the 4/5 days; upgrading to 5 was so risky and so different, that lots of people stayed on 4 long after it was out. I sure don't want to deal with that sort of divide again. The more frequent major release steps are, the smaller and easier they are. Now, you could say "Well, 2(a) just won't be a problem because we'll merge more stuff back". But now all you're doing is making that -STABLE branch _less_ stable, compromising the reason people are using it in the first place. Now, sure, 'stable' isn't a binary condition, and we can always re-evaluate just where we want to stick the needle. Maybe we could be a bit more aggressive about the size of changes we merge back. But I don't believe that we could get _near_ enough backporting to alleviate the time between the big/dangerous new feature landings, without seriously compromising the stability of -STABLE. 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. Now, I don't suggest the current state is perfect. There are certainly relatively minor tweaks like "more common minor releases" that could improve things in some quarters. And they're local enough that they can conceptually be done without rippling out and messing with everything else in the project. But trying to do major shifts aren't as simple as "just make major releases less often"; the tweaks you can do like that all have _very_ seriously side effects, make a lot of things much worse, and would require a lot of _very_ careful rebalancing of everything else to avoid a significant overall lose. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.