I’ve been working a fair bit on Roundup over the past two weeks, customizing it to meet our department’s requirements. During the process I’ve done a lot more than I expected to, and I’ve come to some realizations. First, I think I made the right choice when it came to Roundup. I wanted something that was easy to use, came in a good configuration out of the box, was being actively developed, would be easy to customize and finally – stable and usable. I was also quite influenced by my experience with the Issue Tracker at

In the process, I’ve come to realize the true value of open source. I’ve encountered a number of bugs in the 0-5-maint branch of Roundup (as of today the ones I am concerned about have all been squashed). Although Richard Jones is an excellent project developer (_extremely_ helpful and a pleasure to communicate with – and clean code!) it is impossible for him to fix every problem that crops up. So, out of neccesity, I started to look at the source code – and was pleasantly surprised by how useful it was.

First, I must say that Python is a great language due to its simplicity and the structure it enforces on the programmer (although I don’t agree with nesting levels using indentation – too many potential issues like mixing spaces/tabs etc). What was excellent about Roundup is that the python code is extremely readable. Although I did not know any python before looking at Roundup, it did not take me long to understand exactly what the code was saying and start customizing it to my satisfaction. With the help of Chris Fehily’s excellent Python book (not for experienced users – a nice concise reference), I was able to understand how to extend the code to do what I needed. Much better than Perl ;)

What I am most happy about was my ability to understand and actually fix two problems (granted – very tiny fixes) in the Roundup source. Also, by looking at the source I was able to understand how certain actions could be taken, figure out the exact API and much more. A very pleasant experience. The source code allows use to customize, poke, prod and bugfix to your heart’s desire. No more issues about missing API documentation (although it is _crucial_ in any project to have up-to-date separate API documentation). But the biggest advantage is the learning experience. It has been quite the experience (and despite frustuations, I had a good time) working with the code. If you don’t exactly understand how something works – look at the implementation of the function. If you can’t figure out how something needs to be done, but are fairly sure you know of an implemented module that has to do the same thing – examine the code and find out!

One thing that I would like to see is a better Python debugger. I had to use a _lot_ of print statments…

Anyways, time to boot into my new 2.5.66-mm1 (with AS) kernel and see if it works. now that I actually have the new module-init-tools (Debian users: apt-get install module-init-tools) maybe my loadable modules won’t throw hundreds of errors. Also, let me see if I can see some noticeable changes while doing my usual workload….


Add comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.