Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Jan 2012 15:52:22 -0800 (PST)
From:      John Kozubik <john@kozubik.com>
To:        Devin Teske <devin.teske@fisglobal.com>
Cc:        'Garrett Cooper' <yanegomi@gmail.com>, freebsd-hackers@freebsd.org, WBentley@futurecis.com
Subject:   RE: FreeBSD has serious problems with focus, longevity, and lifecycle
Message-ID:  <alpine.BSF.2.00.1201171525240.19710@kozubik.com>
In-Reply-To: <03a901ccd56d$09eb2a20$1dc17e60$@fisglobal.com>
References:  <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <1326756727.23485.10.camel@Arawn> <CAGH67wS3mvPCBKG36iQ8qtA89GGk1r3KEp4QHj6nt8y9nB8uEA@mail.gmail.com> <03a901ccd56d$09eb2a20$1dc17e60$@fisglobal.com>

next in thread | previous in thread | raw e-mail | index | archive | help

Hi Devin,

On Tue, 17 Jan 2012, Devin Teske wrote:

> I brought this up in last weekend's BAFUG meeting...
>
> We're _very_ interested in replicating the long-lifecycle of the 4-series with a
> newer series. But which one?
>
> Right now, we're jumping to the 8-series, but after seeing that one of the major
> focal points for 9 is McKusick's SU+J (SoftUpdates Journaling -- tunefs -j
> enable), I'm ready to say that the 9-series should instead be the "chosen
> outlier" when it comes to picking one single release to have an ultra-wide
> lifecycle.
>
> The 9-series represents the first release to integrate a journaled filesystem
> by-default into the system (aka boot) filesystem(s). We were pleasantly
> surprised to see that the default installer enabled SU+J by-default when
> choosing "guided" and "auto" for disk partitioning.


There's two parallel suggestions being put forth here, both of which are 
interesting:

- Allow a related party to adopt a release (as I understand it) and 
provide a sub-community taht donates resources to tending and updating 
that release.

- Picking a "chosen" release to really dive into, officially, and polish 
and extend it, like 4.

If I had to pick, I'd say the second one, but I'm not sure either one is 
the right direction.  I think a more sustainable, balanced approach that 
can be extended for every release into the future would be best.

I don't really want to see some semi-official "fork", or "extended 
release" - it would duplicate a lot of existing effort as well as raise 
questions about how "official" it was.  Would vmware support it as a real 
release ?  Large organizations might disqualify it the same way they would 
STABLE.

As for picking 8 or 9 to be the "chosen" exception - that would help me a 
lot in the short term, but if things are being done wrong, they should be 
fixed in the long run.

I think the real choice that has to be made is "when will we halt 
proclaiming two simultaneous releases as production ?" and since 9 is 
already here, it can't be 8/9, it has to be 9/10.  You could progress 8.x 
along its current trajectory, possibly building 8.4 a year or so from now 
and then be done with it, and then that would be the last short/unfocused 
release.

Then you postpone 10.0-RELEASE until January 2017.

Instead of having a legacy branch and two production branches, you would 
have legacy (8) production (9) and ... nothing.  Or if you need to have it 
out there, 10 is the development branch.

Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15 
at the end of the cycle.


On Tue, 17 Jan 2012, Adrian Chadd wrote:

> OP - if you'd like to see FreeBSD's stable release schedule pushed
> forward a bit quicker then please, step up and offer to assist. No-one
> is going to say no. Everyone will appreciate the extra help.


I don't really know how much upheaval is implied in pushing 10.0 to 2017, 
developing only one "production" release, and running 9.x up to 9.15 (or 
whatever) but I can contribute USD $10k per year that this course was 
followed, or $50k over five years.  We can contribute some hardware, 
hosting and bandwidth as well.

Are there any others here who can chip in, or whose firms can ?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1201171525240.19710>