challenge: end of life for 6.2 is premature with buggy 6.3

[Ken Smith]

On Thu, 2008-06-05 at 17:01 +0200, Kris Kennaway wrote:
> Chris Marlatt wrote:
> > Kris Kennaway wrote:
> >> Chris Marlatt wrote:
> >>> In an effort to potentially find a compromise between those who
> >>> believe FreeBSD is EoL'ing previous releases too quickly and those who
> >>> don't. Have those in a position to set FreeBSD release schedules
> >>> debated the option of setting a long term support release, a specific
> >>> release picked by the team to be support for,.. 4 or 5 years? Other
> >>> projects have done this will relative success and considering the
> >>> "only" work required for this release would be security patches the
> >>> work load should be minimized. Hopefully something like this could
> >>> free up more time for the FreeBSD developers to continue their work on
> >>> the newer release(s) while still answering the requests of what seems
> >>> like quite a few of the legacy FreeBSD users. Thoughts?
> >>>
> >>> If this has already been discussed on-list I apologize for beating a
> >>> dead horse but I can't recall it bring brought up before.
> >> Uh yeah, this has been in place for *years*.  Have you actually read the
> >> support announcements?  They are public ;)
> >>
> >> Kris
> > 
> > I do actually - and when was the last release that was support for such
> > a duration of time,.. 4.11? As of recent the longest I've seen has been
> > 24 months with others being only 12.
> 
> Yes, and this is the FreeBSD definition of "long term support".  Don't 
> like it?  Do something about it.
> 

The 4.11 support was an anomoly, to a large degree because you needed to
be either "Really Brave" or "Clinically Insane" to use 5.x.  :-)

It's unfortunate that people seem to be experiencing regressions with
6.3, we do try quite hard to avoid that.  And our support model is
geared up around that, it's typically the last release for a given
development branch that receives the extended support under the
assumption there are no issues with upgrading in-branch.

As for re-defining extended support to mean 4 or 5 years instead of just
two it's not clear us doing that (except for anomolies like 4.11) is
really in your best interests.  :-)  Even if the base system's support
were to be extended to that sort of timeframe it's the *applications*
you folks rely on the most.  The ports folks do their best to keep their
stuff usable for the Project-defined life cycle of the releases which
gets harder the older a given "target" gets as well as needing to cater
to "too many" different branches simultaneously.  Keeping the ports
builds going for longer than two years after the last release of a given
branch just isn't feasible/reasonable.  And if the stuff you layer on
top of the operating system isn't upgradable giving you the warm fuzzy
feeling you're OK because the base OS still receives patches isn't
necessarily a good thing.  Of course there will be people who feel
differently but we need to focus efforts on the average folks.

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith at cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080605/132a6ef4/attachment.pgp