This page is a draft.

I'm developing a prototype tool to help my manage my Debian bug-squashing workflow. I've called it "debgtd", after getting things done, the self-improvement method which has proven very popular in IT culture.

I'm very interested in any feedback or ideas people might have. Please spare a moment to mail your thoughts to jon+debgtd@alcopop.org .

Debian Lenny comes with a fairly out-of-date version of debtd. If you are familiar with this version, you should look at what has changed since lenny.

There's a roadmap for the program which details where it's going.

quick usage guide

At the moment my advice is to not

  • fetch the code (below)
  • run python debgtd.py, or
  • sudo make install and debgtd

Once the gui has appeared, stick the email address you use with the BTS in the text field at the top (or if you have DEBEMAIL defined in your environment, it will already be there) and click the button.

Triaging bugs

Bugs have to be triaged before they appear in the main view. The main view will tell you how many bugs need triaging in the status area at the bottom. Click the "triage bugs" button to begin this process.

the triage window

Each bug that needs triaging will be presented one at a time in the triage window. Move onto the next bug by performing one of the following actions:

  • supply a next action
  • click "sleep" to put the bug to sleep
  • click "ignore" if you are not interested in the bug.

You should try and triage all bugs as soon as possible and in one go. However, if you cannot, you can close this window at any time by clicking "Close".

the main window

Once you have triaged some bugs, they will appear in the main window. Click on the package name column or the severity column to order the bugs. Double-click on a bug to browse to its webpage.

fetching the code

git clone git://github.com/jmtd/debgtd.git

future directions

The code as it stands solves the most immediate problem I had: over 100 bugs reported, some requiring action on my part and some not. I get to weed out those that I am not interested in, either at all (ignore) or in the near future (sleep), and define next actions for the rest.

Once I've cleared the deluge however, there are other aspects of workflow I will try to accommodate.

re-awakening sleeping bugs

Firstly, when you sleep a bug, it should only be hidden temporarily. Bugs should be thawed when

  • an activity happens
  • a certain amount of time has passed

I'd choose an arbitrary time of about one month for the latter.

Detecting activity can be hard. There might be some bug activities that should not re-awaken the bug.