Software Project Management
In order to manage projects efficiently and control the quality of our software, we use a combination of free software tools and ad-hoc bespoke solutions we developed for gluing them together. We use Bugzilla to track bugs and tasks, CVS, Subversion or Darcs for source revision control, Pyle (TonyG’s WikiWiki) for knowledge retention and collaboration, CVSZilla [old link: http://www.cvszilla.org/] for matching source checkins with bugs, our TimeTracker and a collection of scripts that make it all work together.
When we started setting this system up this type of integration was not common in software development. We realized that this must be a requirement shared by many software developers, but a centralized tool failed to emerge.
A few months ago we started hearing about Trac, a free software management hub which does most of what we’d like to be able to do. Trac combines a simple issue-tracking system, a wiki and a source browser which integrates perfectly with Subversion. Unfortunately, the more we looked at Trac the more we realized that while the potential of such a tool is great, Trac itself is way too simplistic for us to be able to abandon our carefully fine-tuned system for it.
– Source Control: Trac uses Subversion, but we’re still using CVS on most projects, mostly because we are watching carefully the recent developments in the free source control arena carefully. Subversion is becoming the default tool for CVS survivors, but there are now many any tools on offer.
– Wiki: Trac’s wiki is cool, but Pyle (and especially the stack of extensions we developed for it on a by-need basis) still does lots of things we can’t get done with a generic wiki.
– Bug / Issue Tracking: This is probably where Trac is missing the most. Bugzilla is a very powerful tool. Sometimes it gets in your way with cumbersome management, but we already rely on so many features to facilitate our work-flow – it would be impossible for us to switch to anything less powerful.
– Permissions: Trac’s permissions system is very simple, and for a commercial company like us that often works on projects with many partners it is just not enough.
Experimenting with Trac
For a recent project we decided to use Subversion as our source repository. Subversion was easy to start working with, and it allowed our partners, who are used to working with Subversion to work on the project effectively. One thing we found missing is a good repository browser. Sure, Subversion works over WebDAV, so you can always point your browser at the repository, but we got used to using a fancy repository browser with syntax highlighting, diffing and a search interface. That’s when we suddenly remembered Trac – maybe we couldn’t use it for the entire tool-chain, but the source browser is certainly superior to anything else we’ve seen. Apart from the source browser itself, Trac provides a timeline view, which aggregates all the activity on the project into a chronological list. Changes to the source code and to wiki pages, ticket activity, all in one long list. I welcomed this feature – previously I’ve been using a script that emails me about every new checkin, but this is just so much more convenient.
Apart from source control and bug-tracking, we’ve started using blogging software for the management of the project. This was a lucky gamble by MikeB, who identified a hole in our communication / knowledge-retention scheme. Wikis are great, but they fail to represent activity in a chronological manner, and so much in project management is, in fact, a serial process. Blogs also seem to reduce the barriers to participation – for some reason we find it easier to post a new entry to the blog than start a new wiki page.
Aggregating the Blog with Trac
Soon after I’ve started using Trac’s timeline I realized that I am now following two lists: one page displays the repository checkins, another page displays free textual entries people on the project posted to the blog. The two lists often correlate (for example: someone would make a change to the way some module works, commit the work, the post an explanation to the blog). Clearly, it would be useful to be able to combine the two lists into one.
With free software there’s only one way to find out – I downloaded the source code for Trac and decided to see how difficult it would be to extend it to grab feeds from our blogs. If Trac is easy to tweak, I thought, than maybe we do have a chance of integrating it into our own system. Turns out it’s really easy – the Trac developers anticipated this need, and as of version 0.9 Trac is built using a components architecture, and there’s a standard format for writing plugins and distribute them.
The rest was entirely unexciting. after an hour I had the plugin written and tested (~50 lines of code, that’s all it takes). After another four hours I managed to install it on our project machine, get disappointed (because it didn’t work), find out that the version of Trac we were using is ancient, from before Trac even had plugins, install from source, then make everything work again and upgrade the database.
You can get the plugin here. Beware – the plugin doesn’t do any caching at all and will request the feeds again and again every time you refresh the Trac timeline. I hope to fix this soon, but until then you should avoid using it to import public feeds from high-traffic sites – if you wont get banned you’ll at least earn yourself a few enemies.
– Trac is the best thing that happened to humanity since the cultivation of chik peas. Finally software project management has a centralized hub almost anyone can use to make the process more effective.
– Trac is beautifully designed and implemented. Extending it is easy and there’s a strong community of developers and users. I will continue to push for faster adoption of Trac, now that I know that it can be made to do whatever we want it to. It’s so much better to invest in extending a well supported product than writing yet another glue script.
 Interfaces in Python?, i hear you say … Python doesn’t have interfaces as part of the language (in the way that Java or C# has them), but more and more Python projects include some kind of interfaces, leveraging the language’s reflective facilities to support contracts. Will the Python community ever standardize on the way it does interfaces, either by including them in the language, or by using a common library for implementing them?
 If you are the nostalgic type, try running Debian Stable on your computers – you’ll get a nice reminder of what the free software world looked like a few years ago. It can be frustrating, and it can make you apprecaite more up-to-date operating systems even more.