Re: One possible bug-tracking system.

[Karl Fogel]

Alex Schroeder <address@hidden> writes:
> Assuming we don't want HTML output and we want simpler input,
> wouldn't a file in outline mode be enough?

What it lacks is the ability to compose & browse bug summaries
organized by severity, assignee(s), search matches, etc.  That kind of
interface is very important for getting an overview of what's going
on and for prioritizing.

Each bug needs to be a first class object, with specific meta-data and
state associated with it.  That could be achieved using outline mode,
but probably we'll want better browsing than outline mode affords.  I
was thinking of a format that is a series of bug entries, something
like this:

   -*- -*- -*- -*- -*-
   Summary:      find-file-noselect fails when used with bleach
   Id:           #73
   Severity:     LOW | MED | HIGH
   Priority:     LOW | MED | HIGH
   Reporters:    address@hidden
   Type:         DEFECT | ENHANCEMENT | FEATURE | TASK
   Status:       OPEN | STARTED | CLOSED
   Resolution:   (none) | FIXED | INVALID | WONTFIX | DUPLICATE | WORKSFORME
   Accepted by:  address@hidden
   Emacs info:
     In GNU Emacs 21.3.50.1 (i686-pc-linux-gnu)
      of 2004-05-16 on mymachine.example.com
     Important settings:
       value of $LC_ALL: nil
     [... etc, etc ...]
   Description:  
     M-x find-file-noselect errors when invoked with bleach.  But it
     is documented to work -- it's supposed to remove all color from
     the file contents if bleach is non-nil.  I think the problem can
     be traced to this line in files.el: ...

   -*- -*- -*- -*- -*-
   Summary:      blah blah blah
   Id:           #74
   Severity:     LOW | MED | HIGH
   Priority:     LOW | MED | HIGH
   Reporters:    address@hidden
   Type:         DEFECT | ENHANCEMENT | FEATURE | TASK
   Status:       OPEN | STARTED | HAVE_PATCH | CLOSED
   Resolution:   (none) | FIXED | INVALID | WONTFIX | DUPLICATE | WORKSFORME
   Accepted by:  address@hidden
   Emacs info:
     [... etc, etc ...]
   Description:  
     [... etc, etc ...]

The idea is we'd have functions for browsing this file in summary
form:

  M-x bugz-browse-all
  M-x bugz-browse-open
  M-x bugz-browse-goto-bug
  M-x bugz-browse-matching

That last one would take a field name (or "any") and a string to
match, and show all bugs matching the string.  By "show", I mean a
separate buffer with optimized movement commands, showing each bug
that matches the request.  Defects would have a red background on
their Type field, so they are immediately obvious, and so on.

Once you've selected a bug, you can jump to it in the master bugs file
(narrowed) with one keystroke, of course, so that changing a bug's
status is just a matter of jumping (either from summary buffer, or via
`bugz-browse-goto-bug') and editing the master file.

Metadata can also be edited directly in the summary buffer, of course.

There would be a function `bugz-attach-mail' and a variable
`bugz-attach-mail-func'.  The variable's value is a function
appropriate for each mail reader in Emacs.  `bugz-attach-mail' would
prompt for a bug ID number.  While reading an email relevant to some
bug, you invoke `bugz-attach-mail', and it appends that email to an
mbox file in a dedicated subdirectory for that bug, a path which is
known to the master bugs file.  (That's the best I can think of right
now for an email tracking system.  We're rather constrained by the
requirement that all the data be in the working copy.  However, we
could eventually set up a system that listens for emails with special
subjects, and automatically files them in the right place and commits
them.)

Of course, all this is easy to say.  Who's going to code it?  I am too
swamped right now to do it :-(.  But I hope maybe someone else will
agree that this approach has promise and whip something up.  Or maybe
there's a system that does something like this already?

-Karl