FreeBSD has serious problems with focus, longevity, and lifecycle

[Mark Linimon]

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