Andy Chilton

Over the past year or so, I've been working on a project called Cil. It's a distributed issue tracker and if you don't know what that means, let me explain.

Cil is currently a command line tool. It saves it's issues, comments and attachments as plain text files inside your project in an issues/ directory. Some settings are read from .cil and also you may set some personal preferences in ~/.cilrc.

Due to the fact that all data associated with issues (bugs, feature requests, tasks) are saved as text files, it's really easy to check them in to Git and, if required, fix conflicts.

Aha, conflicts, that's gotta be painful. Well, it's not and here's why.

Each issue, any comments and all attachments are assigned a random set of hex chars for it's identity. Since this space is so big, the chances of two people adding an issue at the same time with the same identity is minuscule. Hence, conflicts are rarely encountered. Adding a comment to the same issue at the same time might cause a conflict (in the parent issue) but resolving that is simple.

And remember, all issues are saved in Git which gives you two advantages. Firstly it's Git which gives the issue tracker it's inherent distributed nature. Secondly, and this is just as good, you have a full history of all of your issues.

Sweet aye?

Release Early, Release Often

Using cil has completely changed how I create and manage my software releases. Why? Because Cil let's me label issues. This of itself isn't amazing but think about how you can figure out when you're ready to release the next version of the software. Think about the following Makefile:

next-milestone:
	cil summary --is-open --label=Milestone-v0.01

So if at one stage you say make next-milestone, you might end up with list of many issues.

$ make next-milestone
cil summary --is-open --label=Milestone-v0.05
===========================================================================
0085f7a8   New          Add ability to edit comments
2b4647f8   New          Change name of page attributes
2f37e17a   InProgress   Allow Section Properties
65d73568   New          Add new section layouts - Featured Node (or equivalent)
713f4705   New          Using |cfg is bad, it's not a filter anymore, needs changing
7bc0d655   New          Add a SPAM question thing so we don't get all the spam
a4c0e80f   New          Add a 'FlickrImage' node type
ac70e68c   New          Add new ways to render each node
===========================================================================

But one day, after developing day and night, you type make next-milestone and voila, no issues are returned!

$ make next-milestone
cil summary --is-open --label=Milestone-v0.05
$

Joy fills your heart because you know what this means. It means you can release your next version. Too many times I have delayed releasing something but following this procedure means I know when I'm done :)

Getting Things Done

Lately I have also been using Cil as a ToDo list. I know a few other people who do this too and we have yet to compare notes, but here is my latest thoughts on doing it.

With GTD, one of the things they tell you about is contexts. You might be at home or work or somewhere else entirely. In most cases, you can only perform a particular task within a known environment. If you're down the park or at a football match, you'd rarely tick something off your ToDo list.

So I have been labeling my issues with Label: Content-Home and Label: Content-Work. In my Makefile in my ToDo directory, I have the following make targets set up:

home:
	cil summary --is-open --label=Context-Home

work:
	cil summary --is-open --label=Context-Work

By using these targets (along with some other helper targets), I can get Cil to read all the issues, filter on Status (show only the open ones) and filter on issues that have that particular label.

Again, this has been a revelation to me recently. I find I am getting more things done, which I figure is the point of the whole thing :)

Getting Cil

Go to your usual checkout dir and type:

git clone git://github.com/andychilton/cil.git

In my $PATH I usually have ~/bin, in which I place a cil script which I make executable:

$ cat ~/bin/cil
#!/bin/bash
export PERL5LIB=/home/andy/src/github/cil/lib
/home/andy/src/github/cil/bin/cil "$@"

Replace the paths for your checkout. Doing it this way means when you fetch newer versions of cil, you get the updated copy in use immediately.

Have fun and let me know how you get on. By the way, it's written in Perl :)