There is a legitimate discussion to be had about where and how we draw
the line for feature inclusion [...] But the chain of logic from "Linux is about
choice" to "ship everything and let the user choose how they want their
sound to not work" starts with fallacy and ends with disaster.

1. No one cares about what you think, unless you do what you think.
2. No one cares what you do, unless you think about what you do.
3. No one ever really cares what you say.

• The mesa-demos package has a few useful things - teapot in particular is nicely simple.
  
• sierpinski3d and glblur from xscreensaver-gl-extras also work well.
  
• extremetuxracer is, in my opinion, the most fun way to benchmark 3D.

• All .i386 packages have been rebuilt for i586.


• Instead of building four kernel packages (i386, i586, i686, and i686-PAE) we're now building just two kernels: i586 and i686-PAE.


• Newly-installed x86 systems that have 'pae' and 'nx' in /proc/cpuinfo will get i686-PAE.


• Everything else will use kernel.i586.

If you want to ask a question on IRC, NEVER DO THIS:

<someguy> wwoods: ping

What's gonna happen if I'm not there? An hour later when I get back to IRC, all I know is - you wanted something. I have no idea what. So then all I can do is ping you back, and if you're not around, then we have to keep sending pings back and forth until we're both online at the same time.

An empty "ping" is the same as saying "Can I ask a question?" You just did. Just ask the question.

<someguy> wwoods: ping - what's that blue thing doing there?

Now when I get back to IRC, I can actually answer your question immediately. And if I'm online you'll get your answer right then - no need to spend the extra network roundtrip on a useless ping/pong.

Ping with data - ask the question, mention what you wanted to talk about, whatever. Just don't send empty pings. It's a waste of time.

This has been an Unwelcome IRC Etiquette™ lesson
© 2009 Surly Fedora QA Guy Enterprises, Inc. All wrongs reversed.

I've been working on a branch of python-bugzilla that supports multiple different Bugzilla variants. The current version (0.3) only supports the functions provided by Red Hat's Bugzilla 2.18.x. This branch (which will become python-bugzilla 0.4) adds support for the upstream 3.0 and 3.2 WebServices and Red Hat's shiny new 3.2 instance. (Hooray!)

Yes, I'm sure you've noticed that we've updated to Bugzilla 3.2. Besides the shiny new web frontend there's also new and shiny XMLRPC code for python-bugzilla to use. It still supports the old RHBugzilla stuff, and it now supports all the upstream Bugzilla 3.2 services, but there are some additional new-style methods that will someday make their way to upstream Bugzilla - although probably not until 4.0.

The point is this - I'm trying to get python-bugzilla using the new methods wherever possible. This includes a new and slightly different Bug.search() call, and I want to make sure I can make the switch without breaking everyone's existing code.

So here's my request. If you use python-bugzilla, send me your queries - or just a link to the code, if that's too much to ask - and I will do my best to make sure that your code will work, unchanged, with the new upstream(ish) Bugzilla methods.

I'll update soon to talk about what else is new in python-bugzilla 0.4, but having some real-world test code to work with would be a great boon. Thanks!

Everyone knows what Fedora QA does. "They're the testers. They test stuff." Sure, that's true. But.. what, exactly, do we test? And how?

That's where Test Plans come in. A Test Plan is a document that tells the testers how to test something.

1. What special hardware / data / etc. is needed to test this (if any)?
2. How do you prepare your system to test this? What packages need to be installed, config files edited, etc.?
3. What specific actions do you perform to check that the software is working like it's supposed to?
4. What are the expected results of those actions?

Your answers can be short: "get a bluetooth keyboard and yum install bluez-gnome newer than 0.25" answers question 1 and 2 just fine. But they need to be complete and explicit: "Get an appropriate keyboard and install the new packages" is not helpful.

Questions 3 and 4 are answered by Test Cases. A Test Case is a single, specific thing to test - a list of actions to perform, and the expected results of those actions. Depending on how complicated a package or feature is, you could have one Test Case or a whole bunch of them.

While writing a Test Plan, pretend that you have an intern whose job it is to test Fedora releases. This brave, brave soul has a few years' experience as a Fedora user and basic familiarity with using the commandline to configure stuff, install packages, and so on.

Your job is to tell this person how they can test your favorite package or your cool new feature, so they can either a) tell their friends about how great it is, or b) tell you (via bugzilla) if it breaks.

Here's an example Test Case for Banshee, originally written by our own Balaji Gurudass:

Description:

Test loading a Local File in Banshee.

Actions:

1. Start Banshee
2. Choose "Import Media" from the "Media" menu
3. Select "Local Files" from the import source dropdown and click the "Import Media Source" button
4. Select the music file and click Open
5. Find the song in the music library and play it.

Expected Results:

1. Banshee starts successfully
2. The "Import Media" menu item brings up the "Import Media to Library" dialog
3. The chosen music file is imported into the Banshee library
4. The music file can be played and the tracker moves along and shows time elapsed.

So there's an overview of how to write test plans. Currently we're keeping Test Plans in the wiki. There's a section in each Feature Page for a Test Plan, and if you wanted to write a Test Plan for a specific package (or set of packages), you could add a wiki page named "QA/[package] Test Plan". For example, here's QA/Banshee Test Plan.

Next time, I'll talk about why I think this stuff is so important.

1. Install F8Test2 - on a 64-bit machine - with a custom package selection that includes the Development group
   
   This will install rpm-devel-4.4.2.2-0.1.rc1, which (accidentally) includes all the libs that rpm-libs normally provides. The installer will not install rpm-libs, since all the files in that package are already provided by rpm-devel.


2. Boot your fresh new F8T2 system and notice ~150 new updates.


3. Install the new updates.
   
   During this upgrade, yum will upgrade rpm (and friends) to 4.4.2.2-0.4.rc1. This new rpm-devel package does not include the rpm libraries anymore, so yum should notice this and pull in the rpm-libs package, to keep rpm working. For some reason, on multilib (i.e. 64-bit) machines, it does not.
   

# force-remove the old fonts
rpm -e --noscripts $(rpm -q fonts-japanese)
# manually install new ones
yum install fonts-japanese