Where Fedora Went Wrong (nice conclusion)

[Gene Heskett]

On Tuesday 15 May 2007, Todd Zullinger wrote:
>Gene Heskett wrote:
>> On Tuesday 15 May 2007, David Fletcher wrote:
>>>I doubt whether fixing things like this will now be receiving much
>>>priority with the F7 release being imminent, which is a shame. IMHO
>>>there is nothing wrong with using a fast moving distribution like
>>>Fedora, but when a version is getting towards the end of its life it
>>>should be left alone in a fully working state that we can continue to
>>>use until ready to upgrade.
>
>It's a double edged sword.  If something isn't updated for a soon to
>be EOL'd version, some folks get mad and blame the developers for
>neglecting it while it's still supported.

I didn't write the above Todd, but I'd think that (again given a 3 digit IQ) 
that security related fixes should be pushed in the last couple of months 
along with bug fixes that are serious (as in several people have reported it) 
stability problems.  Eye candy that's not well tested is another horse that 
shouldn't even be given a show at the payoff window.

>If it is updated and there 
>are new bugs, it looks bad as well.

Too true, darnit.

>What's needed is more folks 
>jumping in to actually test before the updates get pushed and
>submitting fixes when possible, but filing bugs for them at the least.

I think you might get more 'testing' if it wasn't for installing a rawhide 
item pulling in so much other stuff, with that breaking unrelated stuff, so 
those of us that want to do more with our boxes than serve as a test bed for 
rawhide generally steer clear of it because its an all or nothing repo.  I 
used to run a lot of rawhide stuff, but generally speaking, when it drags in 
50 megs of other libraries just to install a rawhide major item such as the 
gimp or cups, and that breaks another 50 megs of stuff you use everyday, then 
frankly, I'll pass on rawhide.

If I absolutely must have the latest and greatest of something, like cups for 
FC2, which was never fixed throughout the life of FC2, then can you blame us 
for going after the tarball and building our own which, because it was built 
against the currently installed system, works flawlessly, whereas the FC2 and 
rawhide versions both killed half the kde stuff with nothing more serious 
than hovering the mouse over a print related item in the kmenu, probably 
causing at least 50 reboots here.  I came to the list and was ignored, other 
than the mantra of saying its not a bug if its not bugzilla'd.  But the 
version of bugzilla then in use would not allow me to actually file a bug, 
all it wanted to do was search for existing bugs forever.  That IMNSHO ain't 
how to run a bug reporting facility, by denying the un-initiated the right to 
file a bug.  And it damned sure hurts both of us.  I'd try to setup an 
account and by the next day it had forgotten the password it emailed me the 
night before!  I learned to hate bugzilla right then and there, and haven't 
seriously changed my opinion of that POS since.

In desperation, thinking it was a kde problem, I built kde from scratch using 
konstruct.  It ran flawlessly, until the mouse pointer passed over the kde 
print manager, at which point it was reboot time again. ctl-alt-bkspc to kill 
and restart x & kde did NOT restore things.  Eventually something in cups 
bugged me and I was told that only a version update would fix that and you 
weren't about to update the actual version number for FC2 and that I could go 
pound sand.

I did build the newer cups from a tarball, and voila! Not only was the problem 
I was having fixed, but I could actually select, in kde, the print manager in 
the kmenu and (heavens) actually use it to print something without bringing 
the system down.  It Just Worked(TM).  Then I added ghostscript and 
gimp-print-4.27 to the mix and things worked even sweeter,

If you do blame us for that reticence to touch rawhide, then the finger is 
pointing the wrong direction.  Whatever you put in rawhide should be built 
against the existing latest install, not against a gigabyte of the latest and 
greatest libraries on your test system.  If we miss a feature you've added 
because its only available in a library that was just released last week, 
well, so what?

Inversely, if a new library is being built, then it should remain 100% 
compatible with the one it replaces.  No exceptions.

>> I have to violently agree with these thoughts Dave.  I've questioned
>> if this is not some tactic to get us to upgrade by destroying the
>> install we are currently running, just so they have a freshly minted
>> test laboratory again.
>>
>> Maybe that's being paranoid, but the facts certainly suggest it to
>> anyone with a 3 digit IQ.
>
>Not really.  My IQ is at least a few points above 3 (I think) and

Your slight rewording seriously changed the meaning, I was counting digits, 
and it takes 100+ to make 3.  We both pass that 3 digit test by a decently 
wide margin I believe, or at least I did when I was tested 60 years ago.  
Your test, if you've been tested, is probably 50 years newer anyway. :-)

>AFAICT, the main cause of this is simply a lack of available manpower
>to find and fix all of the bugs.  There are not quite 400 people that
>maintain at least one of the 4300+ packages in Fedora.  A lot of folks
>maintain several.  And that's for at least 3 versions at a time --
>more if you count the folks @redhat.com that maintain stuff for RHEL
>as well.

This is without a doubt true, and some are spread pretty thin.  That doesn't 
change the fact that if I want to test the rawhide version of something, then 
its dependency list should NOT require we pull in another 50 megs worth of 
stuff, thereby breaking 1-3 other, in daily use, programs.  We would like to 
test that particular program on our system, NOT test the rest of our system 
against that program.  There is a rather large, and should be obvious, 
difference between the two scenarios.

As it is, to run 1 rawhide program almost always requires you pull the whole 
MaryAnn, and even then you are going to bleed, usually just when you have 
something important to do.

>To paraphrase Hanlon's razor: never attribute to malice that which
>can be adequately explained by lack of volunteers. :)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Information Center, n.:
	A room staffed by professional computer people whose job it is to
	tell you why you cannot have the information you require.