From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Unable to close a bug in the tracker. Date: Wed, 13 Jan 2010 19:27:37 -0500 Message-ID: <87iqb5o7ie.fsf@red-bean.com> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1263428884 31220 80.91.229.12 (14 Jan 2010 00:28:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jan 2010 00:28:04 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 14 01:27:56 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NVDZ6-0001Bh-1g for ged-emacs-devel@m.gmane.org; Thu, 14 Jan 2010 01:27:56 +0100 Original-Received: from localhost ([127.0.0.1]:34253 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NVDZ6-0002Py-PR for ged-emacs-devel@m.gmane.org; Wed, 13 Jan 2010 19:27:56 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NVDZ1-0002Oy-A5 for emacs-devel@gnu.org; Wed, 13 Jan 2010 19:27:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NVDYv-0002Lp-6P for emacs-devel@gnu.org; Wed, 13 Jan 2010 19:27:49 -0500 Original-Received: from [199.232.76.173] (port=45051 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NVDYv-0002Lm-2I for emacs-devel@gnu.org; Wed, 13 Jan 2010 19:27:45 -0500 Original-Received: from sanpietro.red-bean.com ([66.146.206.141]:33339) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NVDYu-0005cT-NN for emacs-devel@gnu.org; Wed, 13 Jan 2010 19:27:44 -0500 Original-Received: from localhost ([127.0.0.1]:60777 helo=kfogel-work ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.71) (envelope-from ) id 1NVDYs-0004Gi-Jv for emacs-devel@gnu.org; Wed, 13 Jan 2010 18:27:43 -0600 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:119943 Archived-At: 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