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: Re: Bug statistics Date: Thu, 24 Jun 2010 14:22:41 -0400 Message-ID: <874ogsthn2.fsf@red-bean.com> References: <1focf1eb1p.fsf@fencepost.gnu.org> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1277403792 30921 80.91.229.12 (24 Jun 2010 18:23:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 24 Jun 2010 18:23:12 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 24 20:23:10 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.69) (envelope-from ) id 1ORr4u-0005xS-JQ for ged-emacs-devel@m.gmane.org; Thu, 24 Jun 2010 20:23:09 +0200 Original-Received: from localhost ([127.0.0.1]:33519 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ORr4s-00050Q-SS for ged-emacs-devel@m.gmane.org; Thu, 24 Jun 2010 14:23:06 -0400 Original-Received: from [140.186.70.92] (port=35451 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ORr4h-0004y1-H1 for emacs-devel@gnu.org; Thu, 24 Jun 2010 14:22:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ORr4f-0004gT-0F for emacs-devel@gnu.org; Thu, 24 Jun 2010 14:22:54 -0400 Original-Received: from osh-net-219-98.onshore.net ([66.146.219.98]:59745 helo=sanpietro.red-bean.com) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ORr4e-0004fg-S7 for emacs-devel@gnu.org; Thu, 24 Jun 2010 14:22:52 -0400 Original-Received: from localhost ([127.0.0.1]:37608 helo=kfogel-work ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.72) (envelope-from ) id 1ORr4W-0000zf-04 for emacs-devel@gnu.org; Thu, 24 Jun 2010 13:22:46 -0500 In-Reply-To: (Richard Stallman's message of "Thu, 24 Jun 2010 11:40:50 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.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:126367 Archived-At: Richard Stallman writes: > 4594 reports [1] > 2647 closed reports > >Amost 2000 bug reports not closed >is rather disturbing. > > 14% have been marked "minor" > 20% have been marked "wishlist" > 9% are tagged "moreinfo" > 5% are tagged "wontfix". > >That is about 40%. It seems to imply there are around 1200 bug >reports which are not marked in these ways, and not fixed either. >Is that true? > >Can you compute the number of bug reports that are waiting for action >by the maintainers? Percentage of bug reports not closed is not in itself a problem. It's possible that bugs-not-triaged is a problem, but that really depends on many things about the project. http://ostatic.com/blog/fixing-the-perception-of-bugs (And yes, I'm quoting someone quoting me in order to give my opinions more authority. :-) ) IMHO the poor web interface of our bug tracker is an impediment to finding and triaging bugs. Heck, I can't even find the tracker half the time. If I start at http://gnu.org/software/emacs and click on the link to [what is purported to be] the Emacs bug database, I am taken to the generic top of the Gnu tracker: http://debbugs.gnu.org/. Then there is a table there, with a row for Emacs. Since what I want to do is search the Emacs bug database, I take the closest option to that, which is the "Browse bug reports" column with its cell for "Emacs reports". Clicking on that brings me to: http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;max-bugs=100;base-order=1;bug-rev=1 That page turns out to be just a random 100 out of many bug reports -- not that this is in any way obvious. You have to actually read the text at the top of the page ("Showing results 0 - 100 of 2003", which of course my eye glazes over because "2003" looks like a date and I'm not interested in dates) to realize that what follows it is unintentionally insincere, e.g.: If you find a bug not listed here, please report it. * Outstanding bugs -- Normal bugs; Patch Available (2 bugs) * Outstanding bugs -- Normal bugs; Unclassified (46 bugs) * Outstanding bugs -- Normal bugs; More information needed (2 bugs) * Outstanding bugs -- Minor bugs; Unclassified (16 bugs) * Outstanding bugs -- Minor bugs; More information needed (1 bug) * Outstanding bugs -- Wishlist items; Unclassified (11 bugs) * Resolved bugs -- Normal bugs (16 bugs) * Resolved bugs -- Minor bugs (5 bugs) That first line is wrong in an obvious way. The remaining lines are wrong in the same way, though it's slightly less obvious. There are far more than 2 outstanding bugs (one presumes). That summary is just referring to the bugs *on the current page*. But for a randomly selected listing page, I'm not really sure what the point of a summary block at the top is. It can, however, confuse people who might think they're looking at project-wide stats rather than page-wide stats. All of which misses the main point: there's no search box. Oh wait, there is. It's all the way at the bottom of the page, where I'd never think to look for it, because these days search boxes are all (sanely) at the top of the page, as befits the single most useful feature of a bug tracker. I don't know if my periodic rants about our bug tracker have any constructive effect. I feel better after them, though. In any case, bug tracker web UI aside, there is nothing inherently good or bad about a growing bug database. An analysis of the number of unique submitters would tell us far more. -K