A small victory!

It took a week and a half, but I now have Beaker up and running. Hooray! I’ve gone through a few automated regression tests and confirmed that, yes, init(8) does work. Not exactly a stunning result, I know, but that’s not the point.

So now I am busily trying to import all the tests I can get my hands on and run them against FC6 Test2. We’re less than two weeks from the Test3 freeze (see Core/Schedule and I want to be ready to put those release candidate trees through some serious testing.

I’ve come to the conclusion that the full RHTS system, while excellent for Red Hat and RHEL, is not necessarily the best choice for Fedora. Fedora needs something that can be run on individual desktop machines, wherever and whenever. It’s nice to have a tightly controlled cluster of test machines in a lab with power control and all that, but I think the more common use case for Fedora is the individual desktop.

Or am I wrong in that assumption? Are the great, silent majority of Fedora users actually running it on racks of machines in datacenters?

I think I need to do some surveying to find out where our testing should be focused.

Advertisements

6 thoughts on “A small victory!

  1. You should be able to build and test things on one or two machines then once you’re satisfied with the test submit it to the Fedora RHTS for inclusion in the normal battery of tests.

  2. discount rack users ~completely
    Anyone who has a rack of machines is, almost by definition, using it for Real Work and is very unlikely to upgrade it to rawhide and set up a test suite. So you’re definitely best off following your instincts and focusing on something appropriate for individual users (who might connect to a master Fedora test server, but won’t set up their own test server.)
    One possible exception to that statement- the Xen/host situation, where a test server might be set up on the ‘real’ box, and a test run on a hosted Xen install on the same box. I’m not sure how much you want to encourage that scenario, though, given the inherent limitations of testing on anything other than the Real Hardware.
    Luis Villa (who needs to set up an OpenID server)

  3. logs
    Being a bugmaster for the RH desktop team (mcepl chr(64) redhat chr(46) com), I strongly believe that better bug-buddy (or reportbug if you wish) would be nice. The most important thing for me would be a) dependencies (“Version-Release number of selected component (if applicable):” is just a lame excuse for missing functionality) and logs (roughly 80 % of all Xorg-related bugs needs NEEDINFO/Reporter “please, send us /var/log/Xorg.0.log and /etc/X11/xorg.conf). The idea would be that every package would be able to register with some central database its requirements for bug reports — what dependencies it is interested in, and which logs/configuration files, etc. could help in debugging.

  4. And 10 days is the outside since we need to freeze, get a tested tree and have stuff synced to mirrors.
    And as with every release… I’ll be so glad to get this one out the door

  5. darn it!
    I was in rdu for the last 2 days for orientation. I wished I had run into you. it would have been good to sit down and figure out what it is you need so we can make it all work.
    drop me an email or find me on irc and we’ll talk some more.

  6. That should be OK, though, assuming whatprovides() is smart enough to resolve virtual Provides. Which it will need to be anyway, since there’s no guarantee about what type of Provides any given package might have.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s