Unable to close a bug in the tracker.

[Karl Fogel]

I committed a fix to bug #5276.  Closing the bug report, however, is
another matter.  I sent mail to <5276-done {_AT_} debbugs.gnu.org>, but
my mail does not appear to have had any effect -- it hasn't shown up in
the bug log, and hasn't closed the bug.

Now I'm going to rant.

For a project like Emacs, a bug tracker whose primary interface is email
is borderline useless.  I mean, look at:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5276

Does the web page UI offer any of the following basic functionality:

  - A way to comment on the bug?
  - A way to change a status of the bug, including closing it?

No.  But it does stimulate the user to wonder about various questions
whose answers, if the user knew them, would be pointless anyway:

  * What is "Toggle useless messages" for?
    (Please don't answer that.  I don't care what the answer is; I just
    care that there's a UI element offering to "toggle useless messages".
    Might as well have a button labeled "Do not click here.")

  * Why would I want to "View this report as an [mbox folder],
    [status mbox], [maintainer mbox]"?  Who is this aimed at?  Certainly
    not the developer.  Nor the reporter.  Nor testers.  Is there anyone
    among the primary users of a bug report who is served by this?

  * Why does the bug report *start* by default with "Message #3"?
    If message numbers aren't going to make sense anyway, better just
    not to display them.

  * Why does the bottom of the bug report say "Last modified: Wed Jan 13
    23:51:14 2010", when the most recent visible activity in the bug
    dates from 6 October 2009?  Maybe if I toggled useless messages, I'd
    see what this other activity was?  <...tries it...>  Nope.  I guess
    they really are useless.  How reassuring.

  * "To reply or subscribe to this bug, see [here]."  Oh, maybe it's
    using the verb "reply" where most other trackers say "comment" --
    maybe these are instructions on how to leave a comment!  So I have
    to *leave the bug page* to go somewhere else to get instructions on
    how to take one of the most basic actions one can take on a bug?
    These sorts of things are normally done with self-explanatory UI
    elements.

In addition to these problems with an individual bug page, there are
more important general problems with the system as a whole:

  1) While it's great to *offer* email as an option for manipulating the
     bug tracker, it's horribly wrong to *require* it.

     Email interfaces are inevitably experts-only interfaces, because
     the UI is owned by the user's mail client, not by the bug tracking
     software.  So the user has to learn a lot of things by rote before
     she can do anything.  Perhaps the user will become much more
     efficient at using the bug tracker once she has learned those
     things -- rather like Emacs itself, in this respect -- but the vast
     majority of users (both reporters and developers) do not have the
     time or mental space to become experts.  I know I don't.

  2) You request an action but you never know when it will complete,
     because it's subject to the whims of email delivery.  

     Remember that, unlike other network protocols, email is actually
     getting *less* reliable over the years, thanks to the spammers and
     the filters we set up in response to them.  Email delivery time is
     now highly variable, and getting more so.  Non-arrival is not only
     possible, but in some cases common.

     Because you don't know when your action will complete, you may be
     blocked for your actions after that.  This is another way of saying
     that an email-based bug tracker cannot honor the UI principle that
     response time is the most important feature.

  3) Although the web UI could, in theory, give instructions on how to
     change the state of the bug, in practice it doesn't.  You have to
     guess at how to change the state, or you have to poke around the
     site, at which point you run across Dostoyevskeyan novels like:

       http://debbugs.gnu.org/Developer#closing
       http://debbugs.gnu.org/Reporting.html#pseudoheader

     My eyes would glaze over were they not awash in tears already.

  4) If you're not subscribed to a bug via email, then manipulating it
     by email involves lots of cutting-and-pasting from browser to mail
     client (i.e., bug number, bug subject, etc).  The response "sure,
     but you're supposed to be subscribed to the bug and do everything
     by email" should be taken out and shot preemptively, of course.  It
     is, again, not practical for non-experts, nor even for experts who
     have just found a bug (via the web) and want to interact with the
     bug starting now.

The Emacs bugtracker is a major drag on my ability to process bug
reports for packages I maintain.  Either I am not alone, or everyone
else is insane.  I trust it is the former.  There is a reason no one
else uses a bug tracker like this (the Debian Project doesn't count:
they are a OS distribution, not an application project, and anyway I've
had to interact with Debian's tracker and it sucks there too, for the
same reasons).

For the love of Cthulhu, why are we using this monstrosity when there
are so many other good trackers out there?  (Launchpad's comes to mind,
but we could also use a library card catalog system with child labor to
run the bug reports slips back and forth.  Or maybe a system where we
put all the bugs in a file, print the file, take a photograph of the
printout, beam the photograph into space, and count on inventing faster
than light travel some day so we can get out ahead of it, recapture the
data, and use time travel (which is about to be invented) to send the
data back to us along with a bug tracker humans can actually use.

While I've been writing this, my closure message to bug #5276 has still
failed to arrive.  The bug report remains open.

-Karl