reviving Fedora Legacy

Patrice Dumas pertusus at free.fr
Mon Oct 13 14:16:23 UTC 2008


On Mon, Oct 13, 2008 at 02:33:51PM +0100, David Woodhouse wrote:
> > 
> > Because it is not the same as you stress yourself. Centos is clearly not
> > the same than 'Fedora-based distribution which is supported for longer 
> > than a year'. It allows to use innovative technologies while not being
> > forced to update each year.
> 
> This is the part I have difficulty understanding. You want to use new
> and innovative technologies, but you don't want to update your nice
> stable system?
> 
> You're right -- you are offered updates, or you are offered stability,
> and there isn't much of a middle ground. But that's just reality.

There can be a change in time, 1 year of innovative technologies and 
then only critical updates, if fedora maintainers are volunteering to
keep on doing critical updates. And I even think that 6 months of
innovative technologies, 6 months with a slowdown in updates, only
important updates, on user demand and then only critical fixes as long
as a maintainer is doing them would even be better.

> > The last jump is not realistic in all cases. What should F6 user jump
> > to? Centos 5? Centos 6? And F8 users?
> 
> F6 is basically RHEL4/CentOS 4 for the most part, isn't it?

If I recall well, FC-5 could be upgraded to RHEL/EPEL, but not a fully
uptodate FC-6.

> And F8 would probably be closest to RHEL5/CentOS 5.

Not necessarily. F8 could already be way ahead from RHEL5/Centos5/EPEL5 
(although it is likely not to be the case in reality since EPEL, for 
instance is relatively new). The reverse is also possible, but if a
maintainer still pushed updates to F-8 until th eend, then F-8 should be
much newer than EL-5.

That being said I'd do what I can to help with having better update
paths, between fedora distros and between fedora and RHEL/Centos, but I
can't see what else I can do, at least for all the packages I 
(co-)maintain. But this doesn't remove the need for more than one year
support on a volunteer basis.

> So no new innovation then? And you'd want to do this for _every_
> six-monthly release of Fedora? Surely that's a whole boatload of effort
> you don't need? Why not just do it for every other release? Or, perhaps
> more usefully, every third release -- a new one about every 18 months?

That's up to the packagers. My hope is that if there is an argeement
than the above is possible, a SIG is constituted and people agree on
that. This may lead to different result depending on what packagers
wants to do.

> I see no fundamental reason why we should _forbid_ people from doing
> security updates for packages in EOL distributions, although I'm very
> wary of the expectations that it would create. If we ship
> official-looking updates for _some_ security bugs, naïve users will
> quite reasonably expect that they'll be receiving updates for _all_
> serious security bugs, and our "You are unsupported; you need to upgrade
> before you get hacked" message will be compromised.

The updates may be pushed to another location than the usual updates
directory, such that it is not in the fedora name.

> I also think that with a niche market that small, between Fedora and
> CentOS, you are unlikely to get enough volunteers to keep it viable --
> isn't that what happened with Fedora Legacy last time? 

Repeating once again, this is quite different from legacy, because this
is the same set of rule, there is no heavy QA, only what is done
normally in fedora, so the entrance barrier is much lower. I personnally
considered helping legacy but is was so different from fedora and so
complicated that I gave up.

> That and/or ensuring that the packages you miss in CentOS are actually
> in EPEL.

I don't miss any package in EPEL, when I miss one I (co-)maintain it. 
Still I'd prefer to be able to suggest people asking me which distro to
choose to use fedora and not ubuntu (in case RHEL/Centos is not the right
distro for them), like I have to do today, because of the one year only
support.

--
Pat




More information about the devel mailing list