[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug tracking (was: new *Help* argument highlighting)

From: Miles Bader
Subject: Re: Bug tracking (was: new *Help* argument highlighting)
Date: Fri, 11 Jun 2004 18:29:34 -0400
User-agent: Mutt/1.3.28i

On Fri, Jun 11, 2004 at 05:11:57PM +0200, Kim F. Storm wrote:
> > Bugzilla and the savannah bug tracker stuff both seem to suffer from the
> > almost fatal flaw that they are almost entirely web-based.  Filing a
> > simple bug report or managing bugs with either is a painful process,
> > because you are largely stuck with the slow manual process of filling in
> > a web form.
> I have entered/updated 1000s of bugzilla trackers, and NEVER found it to be
> slow.  Anything complicated (the description part) can be cut/pasted if
> necessary.

There are two (enormous) problems with web-based bug user-interfaces:

 (1) The web UI cannot do any environmental inspection of your system at
     all.  In the case of emacs, of course, the traditional bug-reportting
     form includes _tons_ of auto-detected data, which is invaluable for
     for analyzing bug reports.

 (2) For the sophisticated user they are extremely difficult to automate,
     whereas an email-based system moves all the work to client where it's
     actually fairly easy (_especially_ for an emacs user, who is often
     using an email client integrated with emacs).

     If you report lots of bugs, or are in charge of bug-handling, a
     web-based interface can become a huge time drain for this reason.

     Note that this is the same old `GUI problem' we're all familiar with
     from other applications:  GUIs are great for occasional use by naive
     users, but when compared to a `language based' approach, they can be
     extremely inefficient for sophisticated users because of the difficulty
     of automation.

`cut and pasting' is absolutely not an answer to (2): it is a time-consuming
and fiddly process unless the entire bug report is a single text field, in
which case you might was well offer an email interface.

For some tasks, a web-based system is probably easier, such as searching of
the bug data-base, so certainly you want _some_ web tools, but you should
also export a simple protocol usable by non-web-browser clients -- see
debian's bug-reporting program for an example (it is client program, and so
can do environmental inspection, but also queries the bug database to allow
the user to make sure they aren't duplicating a bug report).

> To me using web interface for bug tracking makes a lot of sense...
> That doesn't mean that it has to be the only interface though.

If there are multiple interfaces, great, of course -- but I think the entire
functionality of the system _must_ be available via email, except where that
doesn't make much sense (e.g., I'd say that database searching is best left
to other protocols, as email-based query systems are usually too slow to be
very usable).

> > Andrew Suffield's `BugGoo' system, which Tom Lord has started using for
> > tla (replacing savannah's bug tracker), looks interesting.  Andrew is a
> > Debian developer so I presume it is partially based on experience with
> > Debian's bug-tracking system (which is generally excellent, at least from
> > a user's point of view).  http://bugs.gnuarch.org/
> Looks ok on the surface -- but it seems like the only interface, e.g.
> to reassign a bug, is to send mail ... seems clumsy

I think he's only been developing it for about 5 minutes, so yeah, it's a a
bit spartan -- but it's already better than savannah's system for heavy

> (unless of course there is a nice Elisp package to help you with the nitty
> gritty.)

Of course -- but this is simple if you use emacs to read your email (actually
even with reasonably facile non-emacs email clients this shouldn't be too
hard, e.g. make a shell-script called `bugh' and pipe email with commands
like "| bugh reassign kim").

Note that a (huge) advantage of email-based systems is that they make
bug-handling part of your morning email session, where besides being in a
nice familiar environment with easy automation is, it's hard to forget to do
it ... :-) Not a minor issue in practice...

"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi

reply via email to

[Prev in Thread] Current Thread [Next in Thread]