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@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
