2006-03-21

First Steps In The Darc

I had an excellent open source experience today, I have been writing test code for work, and have been progressively replacing year old PBP test code with Twill test code.

When I first looked at twill, less than a week ago, I knew it was the successor, to PBP. I knew what to expect, a nice little interface that allowed me to pretend I was a web browser using a commandline interface.

What I expected was to find a source distribution either using Subversion and Trac, or just straight tarballs.

What I didn't expect was to find that it was distributed by a source control system I had heard of, but never used, Darcs. I fell in love with darcs nearly immediately, because of the following documentation found on the twill website:

To propose a change to the lead developer, make the changes and then do a 'send':
darcs record -am "explanation of change"
darcs send -a

I immediately saw the potential of this system. From the very outset, I didn't feel like I often feel with other projects (Not to single anyone out, but I feel this way with TurboGears and SQLObject), where I feel I can make valueable contributions, but the steps are:

  1. Find problem
  2. Fix problem
  3. Prepare patch from local version
  4. Submit bug in bugtracker
  5. Upload prepared patch
  6. Maintain local fix until patch is applied

I should note at this point that my development host's MTA was broken,
and so the darcs changes I sent didn't get sent immediately

  1. Find problem
  2. Fix problem
  3. Commit Change
  4. Submit Change

Awesome! I already have about 7 patches committed to my local copy of twill, 3 have been sent upstream, but the best bit was talking to the author of twill, we had this (abridged, paraphrased) exchange:

Me: I found a bug, you can't deselect checkboxes.
Titus: Dang, I guess my patch yesterday didn't fix it, can you provide a nonworking example?
Me: I've modified the unit tests, and I'm going to send them to you via darcs.
Titus: I'm going to have blog about it if you do that, fair warning ;).
Me: Oi! I wanted to blog about this first!

The point is, I found a problem in the program, and instead of complaining about it and filing a bug and having to have it triaged and wait for someone to look at it. I found a bug and was able to prepare a unit test. The test gets committed, and no one wants to leave a failing unit test in their code. So it'll get fixed. It'll get fixed good.

This is the way Open Source developers can serve their (technical) users. Allow them to skip the bug tracker. To go straight to the repeatable unit tests.

'rati tags: ,

No comments: