[ditz-talk] ditz-trac update #2

Sean Russell seanerussell at gmail.com
Fri Feb 5 09:15:53 EST 2010

On Thu, Feb 4, 2010 at 10:15 AM, William Morgan
<wmorgan-ditz at masanjin.net>wrote:

> Reformatted excerpts from Sean Russell's message of 2010-01-31:

Yeah, sorry.  Outlook is in use at the office, and I've picked up some bad
habits, like top-posting.  It doesn't help that that's Google's default
mode, too.

> > Out of curiosity, how many people offer you patches?
> Not that many at this point. Possibly because I have ignored people for
> sufficiently long enough that they've gotten the hint. :)

Hm.  Are you aware of any live forks?  I see what appear to be pulls from
clones.  I'd rather contribute, than manage :-)

Personally I find reviewing patches to be more work than writing code.

They can be, yes.

> At least with your own code you understand it (at the time of writing),
> and you don't have to come up with polite ways of rejecting substandard
> contributions.

Eh.  Politeness is overrated.  Case in point: Linus Torvalds.

> > Also, since I value your opinion on these matters, William -- what are
> > you using now for issue management, and why?
> I'm now using Roundup, but I don't like it. I haven't found anything

Oy.  Roundup was good, like, 10 years ago.  Well, it was never "good," but
it was sufficient.  I feel your pain.

> that I like. I do have some concrete ideas about what I want, and it's
> pretty different from ditz, and also from every other project out there.

Different?  How so?  Seriously, I'm dissatisfied with most of my options,

Although, I just got the Eclipse Trac plugin, which offers offline caching,
working, and sync'ing.  I'd still like a command-line interface, but the
plug-in is pretty close to ideal.

My main struggle is with giving up the concept of issues having branch
context. I think that's an extremely powerful feature; just one that's a bit
of overkill for small projects.  It's also difficult to replicate easily
with a traditional, centralized tracker.

> But I am doing my best to avoid starting yet another project that I
> don't have time for.

> > In fact, I'm increasingly convinced from what I've seen that software
> > developers have no more -- and possibly less -- than a 50% stake in
> > issue management; users have the other solid 50%.
> Yes, I think you've hit the nail on the head, and unfortunately ditz has
> pretty bad support for users. There was some work by _why (RIP) to get a
> web interface to ditz going, called sheila, which would have mitigated
> this issue somewhat, but I'm not sure by how much.

Yeah, _why was a great loss.  Sheila was a valiant attempt.  There's just so
much work that's gone into Trac, and Redmine, that would take man-years to
reproduce.  And they're actually pretty decent centralized issue trackers.
The idea of starting yet another web interface and trying to build up to
anywhere near the feature set of one of the established trackers was simply

> FWIW, although I think the ditz CLI and plugin architecture are the
> bee's knees, the major reasons I stopped using ditz were because:
>  a) the lack of a canonical, easily-readible short name for a bug really
>     became irritating;

Hm?  Is this an index vs. hash issue?

>  b) I didn't like having three separate areas for issue discussion: in
>     the commit logs, in the ditz logs, and the mailing list; and

Ah, yes.  Ditz does need a bit more work here.  I think it is easily
solveable, though.  For one, a simple API for fetching a revlog from the VCS
would be almost trivial, and then adding support for individual VCSes would
be simple.  Ditz "show" could easily extract information from all of the VCS
commits that affected the issue, and aggregate that with the normal

A decent tracker web interface with some social engineering support reduces
bug traffic in a mailing list.

>  c) creating ditz issues for bug reports and feature requests from
>     users was burdensome.

Yeah, back the the need for a good web interface.

I don't know, William... it sounds like what you might be happy with, after
all, is Ditz with some integration with a good, online, centralized bug
tracker.  If you have a project that you'd like to play around with, I can
create a Trac instance on my server and you can play with my ditz-trac
integration plugin.  It is crude, but it works, and it might rekindle your
interest in the project.  It can't be worse than Roundup, in any case.

> If I were to design another issue tracker today, I would probably go the
> centralized route. There are some very nice things you get by being
> distributed, but in the long the tradeoff isn't worth it.

I'm currently waffling between working on Ditz further, or writing an
offline, command-line editor for Trac.  The latter might be easier, but
would carry with it some limitations that Ditz doesn't have.

--- SER
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20100205/9b7be141/attachment-0001.html>

More information about the ditz-talk mailing list