long term support release

Horst H. von Brand vonbrand at inf.utfsm.cl
Fri Jan 25 16:00:50 UTC 2008


Naheem Zaffar <naheemzaffar at gmail.com> wrote:

[...]

> Talking as end user (who will always like to be on the latest release
> -so not only is this), would it not be possible to have some natural
> limit to a releases life?

13-ish months, right now. Something like 4 to 7 months more than the
hackers would like to provide on their own. Yes, I'm running rawhide, and
see this (and other) mailing lists and discussions re Fedora. Once version
N is out, a few developers stay to get it working right, the rest flocks to
the exciting world of shiny new packages, baby-munching and brand new bugs
to fix that is rawhide. Same thing has always happened with the kernel, and
Gnome. It is for this same reason that the kernel moved away from the
"stable/development series" split.

> Something like:
> 
> Standard support - what we get now. Around 13 months depending on releases.
> + Reactive support - an additional time period where the community is
> willing

It isn't. Experimental data point. Not just for Fedora, look around at
other community-driven open source projects. The "old/stable/legacy" branch
usually has trouble getting manpower. And there we are normally talking a
couple of years at the most, not the lifetime of e.g. RHEL or Ubuntu LTS.

>         to provide updates to key packages using the same structure
> for the standard updates.

Your key package is useless baggage for me. Who decides?

Some set of key packages (however that is decided) just doesn't find
sponsors willing to keep them up to date. What then? Just letting them rot
is bad for the image of the distribution...

The package I might be interested in keeping alive a few years longer might
interest almost nobody else (yes, has happened to me; kept upgrading it
locally).

>                           For this there MUST be a community member
> willing to provide updates for the key packages - even if it @RH for
> supported releases.

There aren't any volunteers, as this thread has amply shown.

[...]

> A good proposal or total crack?

Please tell /in detail/ what the advantage would be against going with
CentOS + EPEL.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513




More information about the fedora-devel-list mailing list