[ditz-talk] First impressions
ninja at slaphack.com
Thu Jul 31 10:49:38 EDT 2008
On Wednesday 30 July 2008 15:32:22 William Morgan wrote:
> Reformatted excerpts from David Masover's message of 2008-07-29:
> > What I think happened is that a particular area was assuming that
> > ask_multiline (or ask_via_editor) was
> Was...? :)
...I must have been up too late.
...was always returning a string, so it would be expecting an empty string,
and not nil.
> Cool, you're the second person to mention ditz with bzr recently. I'm
> interested to hear about your experience!
Well, once the basic functionality was done -- that is, some auto-adding,
auto-checkin, that Nil fix, and forcing the editor -- it works very well. I
can afford to be a bit more aggressive with checkins, because on the few
occasions I didn't want to check that in immediately, I can just run 'bzr
Couple things I'm starting to notice, though -- one thing I miss from Trac is
the ability to go back and edit other parts of the issue before I submit.
Could probably get the same effect by providing an editor-friendly format (not
yaml) in which to enter a complete ticket. For example:
(empty line here in which to type)
(b)ugfix, (f)eature, (t)ask:
Changing who submitted it isn't a common operation, and is deceptive enough
that it might be worthwhile to only allow this through either hacking Ditz,
or changing the username in setup.
Bugfix/Feature/Task should probably be set to some default, as I'm assuming it
must be provided.
And that format means tapping the up and down arrows will take you between
fields, and saving/quitting will commit the whole thing. (If I have
additional comments, I can do 'ditz comment' later.)
One more thing: For a one-project setup, having to type <project>-123 at the
commandline is annoying. That could be implied.
You'll note that all of these are just UI changes, and everyone seems to
disagree about UI. I have no complaints (so far) about the actual
More information about the ditz-talk