the songs win again
November 12, 2004
Grumpy today. My laptop didn’t show up. DHL has no idea where it is except that it left PA on tuesday morning at 2:22am and it’s somewhere between there and NC. For those of you who are geography-challenged. That’s about 450 miles from Allentown, PA to Durham, NC. On a bad day that’s 8 hours of driving. Now, let’s assume there are other stops at other depots along the way. Fine, fine. Let’s give them a whole day, even. The following things should still be true:
- They should know what truck it is on
- They should know if one of their trucks has been missing for more than a day
- They should know which trucks went into which location and at which time
Since they don’t know the above things we can then be able to assume that their tracking system is only called that because it was built by some person named John Tracking and not because it actually DOES SOMETHING related to tracking packages.
Oh Well, They swear it’ll get here by tomorrow morning. Of course they said that yesterday, too.
I’m going to say this as clearly as I can.
RAWHIDE IS BROKEN
Jeremy, bless him, added python 2.4b2 to rawhide, just for s&g. This caused yum to break b/c urllib2 changed in 2.4 in ways incompatible with urlgrabber in yum. This is not the end of the world and hopefully will be solved one way or the other before long. However, sending me patches that patch major components of python in order to make yum in rawhide work is not the correct answer.
Rawhide is frequently broken, sometimes it is unusably so. Rawhide will eat children, corrupt data, maim your mother and run off with your girlfriend while you’re not looking. Rawhide causes warts, gangrene and the heartbreak of psoriasis. If you’re not fully prepared for rawhide to break. And if you’re not fully prepared to note items that are broken but realize that bugs against a newly-hatched rawhide devel should be filed with care.
In other words, rawhide is not for the weak of mind nor easily intimidated.
When you file bugs against items in a freshly-broken rawhide you should be careful. Steps you should take with much care:
- figure out what change occurred that caused an item to no longer function.
- sit it out for a few days, upgrading as you go (by hand, if necessary) and see if the problem goes away.
- Search very thoroughly for bugs already filed on this subject.
- read the fedora-[devel|test]-list and make sure it’s not already been discussed there as a ‘yah, we have to do X before Y will work again, sorry’ problem.
Now let’s talk about the ‘levels’ of rawhide-ness. I like Jef‘s idea of referring to them like terrorist attack warning levels.
Green: Unlikely that you’ll get much more than interative, bugfix, changes. Installing via Anaconda from rawhide at this time will most likely work. This happens near the end of a release cycle when everthing is in a slushy-freeze place.
Blue: Some stuff is kinda breaking, depends on where you are. Watch out for an application keeling over. Look out for someone deciding that user preferences are an unnecessary luxury. But not much should make your system die and laugh at you. Maybe a couple of missing dependencies but not on any application that’s terribly important. This is often to happen in between Test2 and Test3 of a release.
Yellow: A fair number of things have been replaced. Some new libraries that a lot of programs use. Maybe nothing like glibc or gtk but a fair bit of churn is happening. Watch out for functionality loss in various places, but probably not massive data corruption. Anaconda will be in flux or the package sets will be not-so-installable. In general, this is good to use as a default for rawhide risk level.
Orange: Fairly significant bits that other programs need are moving, a lot. The kernel is in flux and you may find some devices vanish. Often dependencies won’t resolve because one thing got updated but something that requires it didn’t. Things are hard to work around. You’ll want to make sure you specify individual packages you want to update when you use up2date or yum to update. Updating everything will probably be either unsuccessful or a bad idea. This happens a lot before Test1 and between Test1 and Test2 when all the things people know aren’t going to work for the final are rolled out of Test1.
Red: Working libraries, who needs ’em? Alpha versions are things that stability-freaks run. This is WAY out on the bleeding edge. Hell, the people on the bleeding edge think this is crazy. Packages like glibc, kernel, python, perl, gtk, major portions of gnome and kde will be cycled hard and often. This happens most of the times immediately after the final freeze is announced. Everyone wants to get as much broken as quickly as possible so they can start buttoning down where they want to be before Test1 hits the streets in a couple of months. Don’t be here, test with extreme caution. If you do want to test, never test on a machine that has ANY data on ANY partition that you care about. Hell, move machines with data you care about into another room when you’re running rawhide at this risk level. Make sure you can blow away and reinstall this one entirely b/c you’re going to need to. Possibilities here: disk corruption, preferences being lost, devices going away, summoning of elder gods. Things like that.
Today rawhide is probably Orange. It’ll hover somewhere between Orange and Red for a few weeks. Test1 will be called, it will plummet into Yellow and Blue. Test1 will be released, it’ll peak up into Yellow/Orange for a while then back to Yellow/Blue before Test2. Test2->Test3 things tend to stay around the lower sections of the scale. Test3->final release things stay pegged in Blue/Green as much as possible.
This is just my thoughts on what I’ve seen from rawhide for the last few releases. You know, maybe we should ditch the colors concept and give them more descriptive names: Happy, Groggy, Cranky, Martha Stewart, Cthulu