Source open, problem closed
I wrote a while back about trac. I continued to be impressed by it. Although it was fiddly to install, I notice that this should be improved by the next point release, which will be packaged in a python egg. And although the version we’re using is only 0.10.2, it’s proven itself remarkably solid. In fact we haven’t encountered any bugs. Or at least we hadn’t until today, when someone discovered that attempting to attach a small file to a wiki page resulted in an application error.
Up until today we’d been attaching pictures which had always worked just fine. Attempting to upload a small text file resulted in the web browser showing a big red error page filled with the following stack trace.
Traceback (most recent call last):
File "/usr/local/lib/python2.5/site-packages/trac/web/main.py", line 387, in dispatch_request
dispatcher.dispatch(req)
File "/usr/local/lib/python2.5/site-packages/trac/web/main.py", line 238, in dispatch
resp = chosen_handler.process_request(req)
File "/usr/local/lib/python2.5/site-packages/trac/attachment.py", line 361, in process_request
self._do_save(req, attachment)
File "/usr/local/lib/python2.5/site-packages/trac/attachment.py", line 449, in _do_save
size = upload.file.len
AttributeError: 'cStringIO.StringO' object has no attribute 'len'
Trac is a popular piece of software, and I had to believe someone else would have run into this bug. Sure enough, googling AttributeError: 'cStringIO.StringO' object has no attribute 'len' led me straight to trac ticket #4311, and the happy news that this particular problem had been fixed. If you look at the ticket, you’ll notice that it cross-references the actual repository diff of the changes which fixed the problem — a simple three line change to a single file in this case, and a nice demonstration of how trac integrates source control, defect tracking and a wiki.
Since I didn’t want to upgrade our trac installation just yet I applied the patch directly to /usr/local/lib/python2.5/site-packages/trac/attachment.py (the file identified in the traceback), and all was well.
This is of course an every day story from the world of open source software. If you stop and think about it, though, there are several layers of openness.
-
The error message was open and obvious. I didn’t have to search through a server log. Application developers are usually taught hide tracebacks from end users — they’re deemed too frightening. In this case, though, I didn’t even have to leave my web browser to diagnose and find a fix to the problem.
-
Trac opens up its own defect database for public access. As we’ve seen, this provides a great example of trac in action. Many closed source projects would regard it as a sign of weakness to publish this kind of information, though I do think (perhaps due to the influence of the open source movement) this attitude is changing.
-
The source files behind the application were open. All I had to do was tweak one of them using a text editor. No rebuild required.
Articles