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

Les Mikesell lesmikesell at gmail.com
Thu Dec 11 19:08:43 UTC 2008


James Antill wrote:
> 
>>> The problem is that users are asking for contradictory/impossible things:
>>> they want new versions as soon as possible, i.e. the day upstream releases
>>> them, but also updates tested for weeks.
>> That's only contradictory because you make it so.
> 
>  It's contradictory because that's the way the world works.

No, it is just the way fedora works, randomizing fixes and breakage into 
the same repository over the same time intervals.

> Look at Eg.
> RHEL-5 updates vs. Fedora 9 updates. Some of them have even had
> basically the same code, at the beginning.
>  But the RHEL-5 updates go through a 6-9+ month (depending on how you
> count) window of testing, and thus. the end result is drastically
> different. If the end result is actually better or worse than what is in
> Fedora 10 (or even Fedora 9 testing, now) is very much a matter of
> opinion, and depends on how far along the line of slow/conservative vs.
> faster/liberal you actually want to be.

You are confusing a bunch of different issues here.  One is the time 
cycle.  Fedora could work 'like' RHEL but with a faster cycle, but in 
fact it is nothing like that.  RHEL (A) maintains all packages that have 
ever been introduced to the repository so you can install back-rev 
versions or duplicate a tested configuration and (B) makes a concerted 
effort not to introduce untested new-feature code within a major version 
so stability increases over time.  Fedora does neither.

>  There is no magic pixie dust which will turn 9+ months of work into a
> few days (even assuming an equal QA resource).

No one is asking for that.  The problems with fedora are that there is 
no reason to expect any better stability at the end of a fedora version 
than at the beginning, and there is no way to avoid the breakage 
introduced.  Even if you know a set of working package revisions you 
can't update a new machine just to that set once the repo changes.

>>  In the lifespan of a 
>> fedora package, it will exist as a barely-tested release or feature 
>> update, perhaps quickly followed by many updates with needed fixes, then 
>> aging into being mostly well-tested code. But by bundling all the 
>> packages together in rolling updates you make it impossible to avoid the 
>>   barely-tested instances on machines where you can't risk them even 
>> though they may only have a short lifespan.
> 
>  Even if this was strictly true, which it isn't, yum allows you to do
> more than either "do nothing" or "yum upgrade -y".

But what it can do depends on the repository still having the package 
you want, where the reason you want it is that you know it has been 
tested under the conditions you have.

>  However in reality packages don't neatly fit into the above boxes
> equally for all users.

But that is largely because you throw all the packages in the same box 
and keep shaking it up.  There's no way to know what you'll get next and 
no way back if you don't like it.

-- 
   Les Mikesell
    lesmikesell at gmail.com




More information about the fedora-devel-list mailing list