Date: Wed, 18 Jan 2012 17:39:31 -0600 From: "Matthew D. Fuller" <fullermd@over-yonder.net> To: Mark Felder <feld@feld.me> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <20120118233931.GL509@over-yonder.net> In-Reply-To: <op.v8aqs6ii34t2sn@tech304> References: <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org> <alpine.BSF.2.00.1201181034580.51158@fledge.watson.org> <4F16A5B8.2080903@FreeBSD.org> <Pine.GSO.4.64.1201181147450.6287@sea.ntplx.net> <4F1707E6.4020905@FreeBSD.org> <CADWvR2ip=nADz=BLXW%2BuNkyUP4hUf88UkOhSoz%2B0AcY79Hzdag@mail.gmail.com> <alpine.BSF.2.00.1201181141270.19710@kozubik.com> <op.v8aqs6ii34t2sn@tech304>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <john@kozubik.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120118233931.GL509>