Stability and Release Cycles - An Idea

[Les Mikesell]

Rahul Sundaram wrote:
> 
>>> Fedora is most cases, is way ahead in versions and that strategy 
>>> won't work much. You could borrow a few fixes like Fedora Legacy used 
>>> to but that is a small number.
>>
>> It would only work in the versions where the code cycle continued into 
>> RHEL and would take some coordination even there, with the tradeoff 
>> that no duplicate work would ever need to be done on the development 
>> side and there would be no incompatible version jumps to cause trouble 
>> on the user side.
> 
> RHEL mostly freezes on everything and backports fixes selectively with 
> few version bumps in between. Fedora stays more close to upstream and 
> rarely backports fixes. If a security issue affects the recent version 
> of any component in Fedora, you just cannot borrow a fix from RHEL in 
> most cases as a result.

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.

>> But, how many things have big security risks anyway?  In most cases 
>> the ones to worry about are just the kernel, network daemons, and suid 
>> programs - mostly things with standardized interfaces so backing up a 
>> version or two shouldn't break anything.
> 
> You aren't considering things like Firefox which often requires security 
> updates. You cannot just go back a few revisions and just hope to not 
> break anything.  Doesn't work that way. You don't even have to be a 
> developer to be aware of that. Any sys admin would be aware of how 
> brittle things can be.

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.

-- 
    Les Mikesell
     lesmikesell at gmail.com