[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Stability and Release Cycles - An Idea



Rahul Sundaram wrote:

Yes, you'd have to coordinate this once the RHEL cut happens. With the result being something actually useful instead of just another throwaway beta. Fedora could just branch their next version at that point to satisfy people wanting fresh meat every day.

Explain to me, how that would work. Would Fedora ever move to a new upstream version or stay with the same version that RHEL does?

The version where the RHEL cut happens would track whatever happens to RHEL to the point that the update repos could be repointed to Centos when it appears without breakage. If it doesn't satisfy fedora developers to build towards stability even through one version out of 3 or 4, fedora could just start it's next version early to absorb the new untested stuff.

If it moves to a new upstream version, how would you ensure that RHEL security fixes apply on Fedora? Don't use throw away words and explain it clearly.

People claim to have done upgrades from the earlier corresponding fedora->Centos versions, perhaps manually tweaking a dozen or so packages so yum could do the rest. If that can happen without any particular planning, I have to think it would be possible to plan it to work without tweaking.

How is that a particular issue? Even RHEL jumped FF versions in an update, so whatever they do should be acceptable in fedora which doesn't seem to follow any particular policy regarding version stability.

Firefox was just an example. If you are not aware of how either side works, no point in discussing a comparison.

Given the FF and OOo jumps in RHEL, I don't think there is a specific 'how' anymore. But the point is that whatever RHEL does, I wish the fedora release that spawned it would do the same, even if the intermediate releases continue to be throwaway betas and even if it causes an odd jump in the release timing. It would have to result in less work, less incompatibility, less fragmentation, and more usability all the way around.

--
   Les Mikesell
    lesmikesell gmail com



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]