Feature proposal: Extended Life Cycle Support

[Ding Yi Chen]

----- "John5342" <john5342 at googlemail.com> wrote:

> 2009/7/8 Ding Yi Chen <dchen at redhat.com>:
> >
> I don't think this has anything to do with motivation. You have an
> idea and on the face of it it sounds great but even the greatest
> ideas
> can be doomed by the details. If you don't believe me (or Kevin) then
> go for it and when you get to the details you will see exactly what
> we
> are talking about. We are simply trying to save you the time.

You have good deed. But it does not help by simply saying everything break.
As I do have some example to break your claim. :-)

I would like to know, specifically, what packages did you tried
and optionally, why did they fail?

> And if you develop ad-hoc logic (which i had too) which is required
> for it to come even close to working then who is going to maintain
> the
> data that drives this ad-hoc logic? If you think the users will then
> you are likely wrong because the same people who are capable of
> helping with this will find it less effort just to use the latest
> release and build some compatibility packages for the older stuff.

If nobody is willing to provide sufficient data for the ad-hoc logic,
then those packages should be black-listed.

> First of all that largely wouldnt be possible for your proposal. You
> also cant account for differences between releases (different
> releases
> can have the same version but entirely different features and
> dependencies). 

I actually encountered the dependency issue you stated.
but I've solved that before, and I don't think it is impossible to convert
my steps to code.

> Also minimum versions probably aren't enough. You would
> also need maximum versions to make your proposal work.

I've consider that (thus the data file that keep the "correct" dependency),
but thanks anyway.

You may asked how this data file be generated.
Well, at infant stage, it needs to be filled by the early adopters
who crush into bugs. You are free to join the data file building.
Don't use Denture if you are uncomfortable with that.

> You clearly don't know how many ways a package can fail. There are a
> lot of subtle advantages provided by the flow of updates during a
> release but Denture will be completely and utterly outside those
> comfortable walls.

Package fails in old releases and current releases. But it's not end of world.
Either file bug reports, fix it yourself, find alternative ones that do the same
thing, or live with it. 

Given it's experimental nature, don't use Denture on the packages that is critical 
to your life, job or other thing you value much.
Use Denture on the packages that, "It's good to have, but can live without it."

Perhaps that's why I haven't yet got bitten by extra bugs.

> If you really want a run down of some of the issues you will run into
> i can provide although i don't think the list is the place for them.

Please mail me the issues that you encountered. Appreciated.

> 
> I can also tell you the far simpler and more effective solution i
> came
> up with for your use case. It is also a frankly much more efficient
> use of the time. Instead create a program to generate side by side
> installable packages. Then you can use the latest release with all
> its
> features but your old programs that works better on an older Fedora
> has all the libs it needs to run. The whole concept is more
> efficient,
> easier to test, less likely to break systems, less dependent on the
> user, the type of user in your use case could deal with it more
> easily, etc and it also covers most of your use cases on your blog.

I am interested in what you said, what do you mean "side by side"?
 

-- 
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.

Looking to carve out IT costs?
www.apac.redhat.com/promo/carveoutcosts/