long term support release

[Patrice Dumas]

On Fri, Jan 25, 2008 at 10:50:41AM -0500, Jesse Keating wrote:
> On Fri, 25 Jan 2008 16:47:49 +0100
> Patrice Dumas <pertusus at free.fr> wrote:
> 
> > > If an "LTS" release doesn't guarantee stability and timely security
> > > updates, it shouldn't be called LTS.  Maybe "Extended Support" or
> > > "More Volunteer Updates".  But not LTS...  
> > 
> > The name is not the issue, as long as it is understood that it is a
> > volunteer based project. It isn't in the fedora name, but fedora is a
> > volunteer based project.
> 
> What earthly reason would you have to run some old code set, with not
> even close to guaranteed updates, let alone timely ones, with little
> man power behind it, and the opportunity to be ignored by most package
> owners?

You cannot say by advance how a project like that would be successful. I
personally think that, today, the project would not be succesful. It is 
much better than before the merge, because now the infrastructure is not a
real issue, procedures can be the same than in fedora proper (legacy
having very different procedures was for me a real blocker), openness 
has improved. Still the lack of co-ownership will certainly lead to have 
packages left to packagers that have no will to keep on doing vital 
updates in an Updates after EOL fedora. But as time goes by I am seing a
trend of more involvement in other people packages and correspondingly
more expertise in other people packages and also co-maintainership is
improving. This opens more possibility for a successful Updates after
EOL Fedora. At the same time I guess that users who favor stability are
less and less using fedora, so it is not obvious which of these process
is the faster.

As a side note all you say may also be true in fedora (no guaranteed
updates, let alone timely ones, with insufficient man power behind it,
and the opportunity to be ignored by most package owners). It is not the
case for all packages but it happens, and, once again there is no
guarantee.

> And why aren't those reasons satisfied with RHEL/CentOS which doesn't
> have these problems?

I would help for those who want to deploy fedora but don't want to
upgrade at the fedora pace.

--
Pat