This is the blog of John Dulaney, a hacker of Fedora, SCAdian, player of Music, blacksmith, sailor, and consumer of Bacon.
Monthly Archives: July 2011
So, I have not been sleeping well for the past couple of months. In fact, two to three hours of sleep is the norm, and only one hour is not uncommon. This is not a new phenomenon; I go through basically the same thing every summer. As it happens, I am sitting here at 2 AM, writing this and listening to Neil Young.
So, I wind up being rather productive.
There is something substantially different about this year, though. I am no longer living where I grew up, but rather in what was my Grandfather’s house prior to his passing. So, this means no more sitting on a lifeguard stand at the beach and pondering Life, the Universe, and Everything.
Anyway, my big project of late is testing AutoQA.
What is AutoQA, you ask? It is the software suite in development by Fedora’s Quality Assurance team that is designed to test Fedora. You can read about it here: https://fedoraproject.org/wiki/AutoQA
Any way, in order to test the test software, several things are needed. Firstly is a mock-up of the Fedora build system (Koji and Bodhi), although the entire thing is not needed; just the back-ends that actually do the work. I am using the actual back-ends and interfacing with them as necessary. Secondly, one needs an instance of AutoQA running to be tested. This is pointed to our mock-up of the build system as if it was the build system. No new code needs to be integrated into AutoQA itself to handle this. And third, test cases with predictable output are needed.
So, how does this mock-up work precisely?
1. Read test case from file (plain text) that describes location of packages to be run through the AutoQA process and the predicted output of AutoQA if those packages were put through the actual build system. It should be noted that for some tests, almost the entirety of (default) Fedora may be required. From here, it is not difficult to simulate the hooks that AutoQA uses, although different ones are required for different tests. Some of them need to be updated after AutoQA is running, which triggers certain tests.
2. Start up an AutoQA instance and pass as options the test we want to test and point it to our packages in our mock build system.
3. Wait for output to be generated and then parse it. Compare it to expected results.
So, none of this is really difficult. The hard part is in creating test cases that thoroughly check AutoQA. We need tests that will pass AutoQA tests, tests that fail them, tests that fail because of one dependency error, tests that test to see what happens if there is a failure in the build system.
Want to help? We could use it with test creation, and Quality Assurance in general. It’s a fairly easy way to contribute to a Good Thing (Okay, maybe not so easy with test creation, but testing software in general is not that difficult). Go to https://fedoraproject.org/wiki/QA to get started.
P.S. Since I wrote this this morning, I’ve checked my email. Tim Flink has also been working on this project and has got some of the back end stuff I hadn’t done yet up on Git Hub:
A couple of reasons, really. Number one on the list, though, is that QCAD is useless with my drafting style. Let me preach on it.
In AutoCAD, one can simply hit ‘l’ (or ‘L’, but the extra keystroke is not necessary) on the keyboard to draw a line. No clicking in the text box at the bottom is necessary. This makes drawing lines very fast. In QCAD, one has to click on the text box at the bottom, which is very frustrating. The alternative is, like in AutoCAD, to click on the little icon in the toolbar. But wait, rather than then being able to immediately draw a line, one is presented with choices for a bunch of different lines. When it comes down to it, AutoCAD has the same choices, but they all get their own separate icons. It’s just one click, and boom, lines can be drawn.
But wait, it doesn’t end there! When one is done drawing the line(s), one cannot simply hit <Enter> a couple of times and get out of line drawing. It has to be manually done by the little icons on the left hand side.
Then, we get to splines. I use splines probably more than lines when drawing ships. I’ll trace out the stations of a ship with splines, arrange them three dimensionally along the profile, draw in the water lines (which are also splines) and fair everything out to get a nice, smooth hull. Well, since in QCAD all the points in the splines must snap to existing entities, it makes it difficult to trace things out.
Looking around in QCAD, it isn’t bad feature-wise for a 2D drafting program, and has come a long way since the last time I mucked about with it. However, the user interface does not present itself very well for a professional draftsman (which definition I fit, even if in the current economy that’s not how I make my living). For non-professional home/hobby use, it can be made to work, but I wouldn’t even think about doing some of the the things that I do with AutoCAD with it, even 2D (and considering I do the majority of my drafting three dimensionally…).
You know, it’s odd that a Free Software supporter such as myself would choose the proprietary software over the open source. However, in this instance, the open source program just doesn’t cut it. QCAD is probably about twelve years or so behind AutoCAD in terms of development. Sounds like I’ve just given myself a new project…