Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Jan 2012 16:00:07 -0800
From:      Freddie Cash <fjwcash@gmail.com>
To:        freebsd-hackers@freebsd.org
Subject:   Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Message-ID:  <CAOjFWZ7YR8OrEUpEEcLfvTOcr7f=05y9v6aoFxfhbNKRM_2WGw@mail.gmail.com>
In-Reply-To: <4F172B1E.30401@FreeBSD.org>
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> <4F172B1E.30401@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 18, 2012 at 12:27 PM, Doug Barton <dougb@freebsd.org> wrote:
> On 01/18/2012 11:46, John Kozubik wrote:
>> - mark 9 as the _only_ production release
>
> What I've proposed instead is a new major release every 2 1/2 years,
> where the new release coincides with the EOL of the oldest production
> release. That way we have a 5-year cycle of support for each major
> branch, and no more than 2 production branches extant at one time.
>
> History tells us that 2 production branches is a goal we can achieve,
> with the focus shifting more heavily towards only bug/security fixes in
> the oldest branch after the new production release branch is cut. If we
> combine that with the ideas that are being put forward about teams that
> "own" a production branch, and a more frequent stripped-down release
> process, I think this is a very workable model.

This is similar to how Debian works (the other OS we use the most often).

They have "testing" (aka -CURRENT) where all the new development takes
place, that will eventually become the next major release; "stable"
(aka production -RELEASE) which sees minor (actually, point) releases
every few months; and "oldstable" (aka legacy -RELEASE) which sees no
development beyond major security/bug fixes.

There's approximately 2 years between major releases, at which time
"oldstable" is EOL'd, "stable" becomes "oldstable", "testing" becomes
"stable", and development continue with the new "testing".

I can see something like that working for FreeBSD, as you've outlined
it above.  It seems to work well for them, although it's not a perfect
comparison since the Debian devs don't do a lot of development on
their own, it's more integration and testing work with software from a
bunch of other, independent projects.

What would be really nice, though, to help with the above, is a
branched ports tree that followed the same release schedule.  Perhaps
it's time to dust off my coding skills and jump back into port
maintenance.

-- 
Freddie Cash
fjwcash@gmail.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOjFWZ7YR8OrEUpEEcLfvTOcr7f=05y9v6aoFxfhbNKRM_2WGw>