FreeBSD has serious problems with focus, longevity, and lifecycle

[Robert Watson]

On Tue, 17 Jan 2012, Andriy Gapon wrote:

> on 17/01/2012 00:28 John Kozubik said the following:
>> we going to run RELEASE software ONLY
>
> My opinion: you've put yourself in a box that is not very compatible with 
> the current FreeBSD release strategy.  With your scale and restrictions you 
> probably should just use the FreeBSD source and roll your own releases from 
> a stable branch of interest (including testing, etc).  Or have your own 
> "branch" where you could cherry-pick interesting changes from any FreeBSD 
> branches.  Tools like e.g. git and mercurial make it easy.  Of course, this 
> strategy is not as easy as trying to persuade the rest of FreeBSD 
> community/project/thing to change its ways, but perhaps a little bit more 
> realistic.  You can bond with similarly minded organizations to share 
> costs/work/etc.  It's a community-driven project after all.

Suppose for a moment we get the .x release process fixed: we start cutting 
regular point releases from -STABLE on a 6-month cycle (just a strawman). 
freebsd-update's update and upgrade features actually make tracking -STABLE at 
release engineered time slices plausible.

One reason that's true is that between 5.x and 6.x, the FreeBSD Project 
underwent a substantive change in our approach to binary interfaces.  In 4.x 
and before, the letters "ABI" rarely hit the mailing lists.  In 6.x and later, 
it's a key topic discussed whenever merges to -STABLE come up.  We now really 
care about keeping applications running as the OS moves under them.  We also 
build packages to better-defined ABIs -- not perfectly, but OK.

I think John gets a lot of what he wants if we just fix our release cycle.

Robert