reviving Fedora Legacy

Patrice Dumas pertusus at free.fr
Tue Oct 14 08:07:37 UTC 2008


On Mon, Oct 13, 2008 at 08:36:50PM -0400, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
> > > On the contrary. The Fedora project provides maintenance of the release
> > > for the release period. You're guaranteeing ... nothing.
> > 
> > It provides maintainance, but cannot guarantee anytihng.
> 
> Be realistic. If we didn't de-facto guarantee that we'd provide security
> updates during the specified lifespan for all relevant packages, we woudn't
> have a viable distribution.

Sure. I exactly the same in response to your first mail. There is a
de-facto guarantee, but nothing substantial to fedora. And specific
packages can go unmaintained, important bugs can be unfixed and so on...

> > The idea is to 
> > provide maintainance for the packages people are interested in providing 
> > maintainance.
> 
> I know exactly what you're proposing, you don't need to restate it. I just
> think it's a fundamentally bad idea that actively harms users by giving
> them an open-ended rope to hang themselves with, which doesn't at all claim
> to cover their entire system, as opposed to the clear support and
> maintenance they have now.

If it is clearly communicated, and requires manual steps to set up, with
a clear comunication (well as clear as possible) I can't see where is
the issue.

> To put it a different way - would you buy a car whose extended warranty
> won't tell you what it covers, or for how long, and tells you it's subject
> to change *AT ANY TIME*? If so, I think I've got some cars to sell you.

Once again fedora cannot make that claim either.

> You want me to support your plan? Cover the entire distribution, for a
> specified period of time. Simple, right?

Unneeded and impossible (at least in the short term). First there is no
point in covering the parts that are not central to the distribution.
And then covering parts is much better than covering nothing. And I
recall you that the plan is to see how many people are interested before
doing anything publicly.

> > > ... but then later want a longer term of support, up to 3-5 years, during
> > > which... their OS will be old. Just as old as an equivalent RHEL/CentOS,
> > > in fact.
> > 
> > Not at all. Centos starts already old, it is very different.
> 
> How so? When Centos 5/RHEL 5 is released, it's pretty much up to date, or
> at least within 6 months. If you're looking for a 3-5 year lifespan (which
> you said your goal is), that's nothing. And halfway or so through your
> proposed arrangement, your release would be just as old and outdated
> as an equivalent RHEL release of the same vintage.

Of course, but it would have started from something recent. And if you
begin at any other time than time of a RHEL release which doesn't happen
very often, there is absolutely nothing for you.

> > It is very different because the updates are not fundamental changes,
> > like those that happens between releases. You know that, don't you,
> > those changes that goes through rawhide.
> 
> ... how so? There's a ton of changes between kernel-2.6.25 and kernel-2.6.27.
> KDE-4.1 is a fairly big step from KDE-4.0. The entirety of system
> network configuration support was added between F8 GA NetworkManager
> and the F8 updates version.
> 
> Is it *all* of the large changes? No. But it's more than you'd think.
> Moreover, exactly which of these big changes break people? Is
> rhgb -> plymouth a big change? Sure. Does it actively break third-party
> applications or development? No.

That's exactly the point. The changes in stable release break less than
between releases. I really can't see why you can't agree to that with
your level of knowledge of th edistro.

> Honestly, I think a whole lot more of the work here is best done:
> - promoting RHEL/CentOS as the alternative for users who need longer support
> - making distribution upgrades seamless and easy

It isn't exclusive. But it isn't the same and doesn't solve the same use
cases. I am already personally very involved in EPEL (all my packages
are in EPEL since long), and I can't see what I can do for distribution
upgrades to be seamless and easy, except for my own packages (and those
I co-maintain).

--
Pat




More information about the fedora-devel-list mailing list