Re: Why Emacs needs a modern bug tracker

[Mark Linimon]

On Thu, Jan 10, 2008 at 06:23:40AM +0200, Giorgos Keramidas wrote:
> FreeBSD has a very active Gnats admin, Mark Linimon, who spends a *lot*
> of time working with the members of the `bugmeister' team to keep things
> going.

To be fair, most of the time I spend on maintainance is spent on what's
inside the database rather than maintaining the thing itself.  We do have
a number of scripts (auto-assigners, auto-reminders, etc.) that we have
layered on top of it.  These do much of the maintainance work.

Having said that, opinions on GNATS within the FreeBSD community are
sharply divided.  Like CVS, it is a dull stone axe, whose appeal is
that people are familiar with the paradigm, and all the rough edges are
well-known.  Without the auto-assigner, I think it would already have
collapsed under its own weight -- and we only have the auto-assigner
for ports.  I will accept the argument that it already _has_ for src.

The problem with replacing it is that IMHO we have to understand how
people really want to interact with a tool before implementing a new
one.  This is much more a 'define the problem' area rather than 'pick
an existing thing and install it'.  (There are those inside FreeBSD who
have been advocating that e.g. Bugzilla or Trac will solve all our
problems; my view is that until we model our desired workflow, we may
just implement something else that does _also_ not meet our needs).

I don't think I would recommend GNATS for a new installation, unless
the number of bugs is expected to be small and the number of developers
limited.  Its search and classification capabilities are simply not up
to modern standards.

There is also the problem that the backing store is a set of flat-files
rather than a true database.  This means that it's difficult to add new
queries.  (My own software at portsmon.freebsd.org simply grabs the
contents of the database and uses some magic to convert much of its
metadata into SQL, so I can integrate it with our ports build cluster
output).

If you want to look at what we've added to the GNATS web interface, play
with http://www.freebsd.org/cgi/query-pr-summary.cgi?query.  It's more
usable than the default that came with it; I consider the work there
necessary but insufficient.

Final note: in my last full-time job we evaluated a number of problem
report trackers (both commercial and open-source) and concluded that
they *all* stink.  Most seem to have been written by some guy like me
who is more interested in laying out fields in a database and designing
a pretty UI, rather than going through the hard work of designing use-
cases, proposing strawmen, and going through a period of working with
all the interested parties to get a buy-in.  But even though that's my
default mode, I know it won't produce the desired result in this case.
(I'm intending to work on that this year).

To summarize, implementing a bug tracker is more a peopleware problem
than a technical problem.  As such, it is much harder to get a handle on.

mcl