What Fedora makes sucking for me - or why I am NOT Fedora

[Les Mikesell]

Arthur Pemberton wrote:
>>> We would be using Ubuntu
>>> or CentOS or any of the other bazillion conservative distros otherwise.
>>> A distro with a 6-month release cycle, but conservative updates, already
>>> exists, it's called Ubuntu, why do we need to copy it? If you want Ubuntu,
>>> go use Ubuntu.
>> CentOS is not only "conservative", as a copy of RHEL and completely
>> different release cycle it doesn't offer any release that is close to
>> Fedora 8/9/10. Colin has mentioned (essential) differences between Ubuntu
>> and Fedora. There are more. Ubuntu won't become equal to Fedora if it
>> increased its updates frequency.
> 
> 
> We will have to agree to disagree on this as I found none of the
> reasons he gave substantive.

Does that mean 'your' reasons for not waiting a week longer are 
substantive, but other people's reasons for wanting something between 
that and the two year's delay you get with Centos are not?  I'd consider 
both not wanting your machine to break regularly and not wanting to wait 
two years for a new feature to be substantive.

 > I'll wait to see what looks like may be a
> new pace of releases play out. I will say that I find the tone of the
> proposed changes to be overly conservative and overall unfortunate.
> But if that's what the majority wishes, so be it.

I still believe that with some minor changes you could please everyone, 
including people who want a different pace on different machines.  You 
just need a fast-track, slow-track scheme for installing updates and 
some cutoff (say 3 months in) for feature-change updates to a release.

It doesn't matter if the fast/slow update tracking is done by 
manipulating different repos (perhaps some changes to updates-testing or 
adding another similar layer) or some clever tricks in yum, as long as 
there is a way to push emergency fixes ahead to bypass any breakage 
noticed at the fast-track level.  That way, testing/development machines 
and people who want to live on the edge still proceed as normal, and for 
machines when you need to control the risk you would upgrade 3 months 
after release and configure the slow-track updates (exact time to be 
determined by observing your test machine).  With such a scheme in 
place, the only extra human work would be deciding when and how to do 
the emergency fixes, but that only comes into play when something 
breaks.  Worst-case, you just stop updates on the conservative machines 
until the test machine shows the fix is done and time has elapsed to 
move it to the slow-track.

-- 
    Les Mikesell
     lesmikesell at gmail.com