Ditz versus bugs everywhere

A few months ago, I sketched out a ticket-tracking system that would be married with my source code. Then some commenters told me about bugs everywhere (be) and ditz.

I’ve looked at both, but I’ve been using ditz full-time while just watching be. Anyhow, here’s a few comparisons:

setting up a project

Here’s what it looks like when you set up a project in ditz:

$ ditz init
I wasn't able to find a configuration file ./.ditz-config.
We'll set it up right now.
Your name (enter for Matthew Wilson):
Your email address (enter for [email protected]):
Directory to store issues state in (enter for .ditz):
Use your text editor for multi-line input when possible (y/n)? y
Paginate output (always/never/auto)? auto
Project name (enter for scratch):
Issues can be tracked across the project as a whole, or the project can be
split into components, and issues tracked separately for each component.
Track issues separately for different components? (y/n): y

Current components:
None!

(A)dd component, (r)emove component, or (d)one: a
Component name: documentation

... snip ...

(A)dd component, (r)emove component, or (d)one: d
Ok, .ditz directory created successfully.

And here’s how you can create a single issue.

$ ditz add
Title: Write something justifying yet another web framework
Is this a (b)ugfix, a (f)eature, or a (t)ask? t
Choose a component:
1) scratch
2) documentation
3) model code
4) controller code
5) view code
Component (1--5): 2
Issue creator (enter for Matthew Wilson ):
Added issue documentation-1 (e8a4a43f78ee83300cc0372a13375d9534b97abb).

You can’t tell, but when I punched in the title, ditz opened my $EDITOR and I wrote a longer description in there.

Now the same thing in be:

$ be set-root
Guessing id 'matt '
No revision control detected.
Directory initialized.

$ be new 'Write something justifying yet another web framework'
Guessing id 'matt '
Guessing id 'matt '
Created bug with ID 4d4

Not quite the same experience!

Here’s what a ditz issue looks like:

$ ditz show documentation-1
Issue documentation-1
---------------------
Title: Write something justifying yet another web framework
Description: Why not just polish any of the ones already out there?
Type: task
Status: unstarted
Creator: Matthew Wilson
Age: four minutes
Release:
References:
Identifier: e8a4a43f78ee83300cc0372a13375d9534b97abb

Event log:
- created (matt, four minutes ago)

And in be:

$ be show 4d4
Guessing id 'matt '
ID : 4d4e6a17-2097-42bb-a3cd-3c17566ecce8
Short name : 4d4
Severity : minor
Status : open
Assigned :
Target :
Creator : matt
Created : Mon, 22 Dec 2008 20:25 (Tue, 23 Dec 2008 01:25:04 +0000)
Write something justifying yet another web framework

Ditz issues have titles, long descriptions, types (feature, bugfix, or task), releases (optionally) and links to components (also optionally). There are ditz plugins to add support for assigning issues to people.

be has most of the same concepts, just with different names.

data serialization and storage

ditz makes a .ditz directory at the top of a project and be makes a .be directory in the top of the project.

Inside the .ditz folder, there’s one project.yaml file that lists releases (groupings of issues) and components (also groupings of issues, but cross-cutting). Then each issue lives in its own yaml file, and they look like this:

$ cat .ditz/issue-ac3177b3bf8c6757625977ef27279c1fe05df662.yaml
--- !ditz.rubyforge.org,2008-03-06/issue
title: Write some "WHY?" documentation
desc: Justify the existence of this project.
type: :task
component: documentation
release:
reporter: Matthew Wilson
status: :unstarted
disposition:
creation_time: 2008-12-23 00:59:05.840956 Z
references: []

id: ac3177b3bf8c6757625977ef27279c1fe05df662
log_events:
- - 2008-12-23 00:59:05.841349 Z
- Matthew Wilson
- created
- ""
- - 2008-12-23 01:08:58.605955 Z
- Matthew Wilson
- commented
- |-
Yeah, if you're gonna build another web framework, this needs to be
really good.

Meanwhile, be is fairly similar, but bugs get whole directories to themselves. be uses what seems to be a home-made plain-text format for storing bugs:

$ cat .be/bugs/4da8ee85-9353-4a92-a654-8510bb8be0d0/values

creator=matt

severity=minor

status=open

summary=Write some "WHY?" documentation

time=Tue, 23 Dec 2008 01:12:13 +0000

There’s actually much more whitespace than that. I replaced the eight blank lines between each line of text with just two blank lines.

While ditz stores the comments inside the issue’s yaml file, be makes a directory under the issue’s directory, and then stores the text of the comments in one file and the information about who said it in a separate file.

The community

The ditz mailing list is really active with people debating ideas for new features. The be mailing list is now showing some signs of life after looking dead in August.

What ditz has that be lacks

ditz can make really pretty HTML pages for all the issues for a project. example.

yaml was a really good choice. yaml makes it easy to deserialize to higher objects than just crappy boring primitive types like arrays. Instead, you can hop all the way to your own weird home made objects by specifying a tag. Then all the stuff in the yaml file gets passed in to your object.

Ditz has lots and lots of commands that are only on the be roadmap. You can search your issues with regular expressions with ditz grep, you can claim issues for yourself, you can group issues by releases and components, etc, etc, etc.

The ditz issue data model can be extended with plugins. Like I mentioned earlier, one plugin makes it possible for people to claim issues as assigned to them.

What I like about be

It’s written in python. I hate to feed the python snobbery monster, but there are certain python niceties that I don’t like doing without. In particular, ipython is just too awesome. When I read the ditz code, I spent most of my time navigating the code to get to the part that I cared about that. With ipython, I don’t have that problem. I just hit foo?? and immediately see the source code.

And ruby’s documentation is not what I’ve grown accustomed to with python. For comparison:

I think the Python docs have more explanatory text in just the table of contents.

In addition, ditz uses a lot homemade code: there’s a homemade option parser library (trollop), a homemade hack on the way ruby stores data files so that all the HTML templates are available, and all sorts of gymnastic FP tricks to get a lot of shit done in a very small number of lines. That’s cool, but as a yellow-belt in Ruby, it is really @#$ing hard to make any contributions to this project. Here’s some code that I find a little difficult to read:

def operation method, desc, *args_spec, &options_blk
@operations ||= {}
@operations[method] = { :desc => desc, :args_spec => args_spec,
:options_blk => options_blk }
end

operation :stop, "Stop work on an issue", :started_issue do
opt :comment, "Specify a comment", :short => 'm', :type => String
opt :no_comment, "Skip asking for a comment", :default => false
end

def stop project, config, opts, issue
puts "Stopping work on issue #{issue.name}: #{issue.title}."
issue.stop_work config.user, get_comment(opts)
puts "Recorded work stop for #{issue.name}."
end

After tracing through a few hundred lines of stuff like that, I usually get discouraged and just write a feature request rather than a patch.

In summary

I like ditz. I like reading nearly inscrutable Ruby code to see how wacky people solve problems. My experience with ditz so far has been about an A minus, which is pretty good!

Why I’m going to write my own

There have been a few times where the lack of a proper database system has bit me. Like when I renamed a release, I had to do some searching and replacing in lots and lots of files. Also, regenerating my HTML views is taking almost two minutes now that I have so many issues. Also, certain operations, like moving a handful of issues from one release to another, or searching for intersections of issue subsets, are trickier than what they should be.

Besides all that, I’m fascinated by couchdb, and I think this would be a good use.

I think my system is going to use a local couchdb server that loads in all the issues from local yaml files into the server on startup. Then after lots of work updating, I’ll write out all the issues back into yaml. So, when you update your checkout of your code, you’ll need to restart or reload your couchdb server. Then you can use the couchdb server to work with the system, and then at the end, re-serialize the data back out to JSON, and then to yaml.

ditz and be are sort of like old-school CGI web apps where each user action has to start up some the framework, do the action, then tear down. My system will instead keep all the issue data in memory and require explicit startups and shutdowns.

12 thoughts on “Ditz versus bugs everywhere

  1. Nope, didn't know about git-issues. Thanks for the link! It's always
    good to see how different people tackle problems.

    After reading the README, I have a few half-baked objections:

    1. The issues are stored in a separate branch. So, as far as I can
    tell, it wouldn't be obvious if one branch of code has resolved an
    issue while another branch hasn't.

    2. It's git-centric. I like git, but I don't like the idea of forcing
    hard-linking the ticketing system to a particular version control
    system.

    These aren't deal-breakers, these are just stylistic differences I
    have with the author.

    Anyhow, thanks again for the link.

    Matt

  2. You have been awesome with your work, keep going like this, subscribing you right away, will definitely be back.

    Emma

  3. quiet good.. I think the Python docs have more explanatory text in just the table of contents.. 🙂

  4. It's fulfilling to think that your working hard just to reach your goal. You're so resourceful to the extent of achieving and keeping all the issue in memory.

  5. Did you hear about the fellow that was talking to his buddy, when he said, “I don't know what to get my wife for her birthday. She has everything, and besides, she can afford to buy anything she wants. So, I'm stumped.”

    His buddy said, “I have an idea. Why don't you make up a certificate that says she can have two hours of great sex, any way she wants it. She'll probably be thrilled!” So the first fella did just that.

    The next day his buddy asked, “Well, did you take my suggestion? How did it turn out?”

    “She loved it. She jumped up, thanked me, kissed me on the mouth, and ran out the door yelling, 'I'll see you in two hours'.”

    Thanks
    Peck
    ______________________________________________
    british heart foundation diet | cayenne pepper detox | diets for quick weight loss | easy diet plans | maple syrup detox | miracle cabbage soup diet | sugar busters diet | weight gain diets | british heart foundation diet | cayenne pepper detox | diets for quick weight loss | easy diet plans | maple syrup detox | sugar busters diet | weight gain diets | miracle cabbage soup diet | miracle cabbage soup diet | cayenne pepper detox | maple syrup detox | british heart foundation diet | weight gain diets | easy diet plans | sugar busters diet | diets for quick weight loss | white light teeth whitener | home remedy teeth whitening | home remedies for teeth whitening | smile brite teeth whitening | white light teeth whitening system | white light teeth whitening | teeth whitening carbamide peroxide? | blue light teeth whitening? | dermalogica moisturiser | dermalogica stockists | dermalogica special cleansing gel | dermalogica skin smoothing cream | dermalogica salons | dermalogica oil control lotion | dermalogica multivitamin power firm | dermalogica medicated clearing gel

  6. Storing them in a seperate branch is IMHO much more elegant than having a separate directory or a database. Git it's self is already more or less a database under the covers,it uses a key value system much like couchdb. The porcelain is just a wrapper around it. The main difference is that if your using git, it already exists in your project.

    Note it only stores the issues related things in a separate branch. Nothing else. If you resolve an issue, or create a bug it all gets stored in one branch. When you commit, and resolve the issue/bug it adds the sha1 which is unique in the entire tree accross all branches. So you can not only tell where it is fixed but you can cherry-pick or merge at your leisure. Also, before you say keeping the issues is memory is faster, in theory this is correct. However git is very fast and the (guessing http ) overhead to couch is such that if you actually try this out ( at least for me ) git was marginally quicker.

    The problem you mentioned with it being git-centric still stands.

  7. So did you get to start your own project or should I go and look at be or ditz?

  8. I made pitz (http://pitz.tplus1.com/) and it works OK. It doesn't do everything that I wanted, but it is an acceptable command-line to-do tracking program.

    If you want to try out pitz, clone the project, then run python setup.py develop, then you can see how I track the to-do tasks for pitz in pitz itself by doing this:

    # make a virtual environment first

    $ git clone https://github.com/mw44118/pit

    $ cd pitz

    $ python setup.py develop

    $ pitz-todo –color –limit 10

    Be prepared to wait! That last command has to load in like a thousand files and parse the yaml in each one. This is the biggest wart right now. Pitz gets unacceptably slow when there are like a thousand or more yaml files.

    I'd love to hear what kind of a tool you are looking for. I've taken a
    break from developing pitz, but I still use it to keep track of several
    different to-do lists, and when life permits, I'll return to it.

    Matt

Comments are closed.