On Mon, Oct 13, 2008 at 08:36:50PM -0400, Bill Nottingham wrote: > Patrice Dumas (pertusus@xxxxxxx) 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
