From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: linimon@lonesome.com (Mark Linimon) Newsgroups: gmane.emacs.devel Subject: Re: Why Emacs needs a modern bug tracker Date: Thu, 10 Jan 2008 00:46:12 -0600 Message-ID: <20080110064612.GA5607@soaustin.net> References: <20080105214810.GZ30869@thyrsus.com> <20080105233923.GH30869@thyrsus.com> <18304.10442.537860.246188@kahikatea.snap.net.nz> <87k5mnoge1.fsf@catnip.gol.com> <8763y7o719.fsf@catnip.gol.com> <87r6gt7l7i.GNU's_Not_Unix!%yavor@gnu.org> <20080110042340.GB12523@kobe.laptop> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199953076 6148 80.91.229.12 (10 Jan 2008 08:17:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Jan 2008 08:17:56 +0000 (UTC) Cc: Mark Linimon , emacs-devel@gnu.org To: Giorgos Keramidas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 10 09:18:18 2008 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 1JCsc7-00077e-39 for ged-emacs-devel@m.gmane.org; Thu, 10 Jan 2008 09:18:13 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JCsbj-0007Tb-Hp for ged-emacs-devel@m.gmane.org; Thu, 10 Jan 2008 03:17:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JCrBA-0001cS-Ay for emacs-devel@gnu.org; Thu, 10 Jan 2008 01:46:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JCrB9-0001bm-OJ for emacs-devel@gnu.org; Thu, 10 Jan 2008 01:46:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JCrB9-0001bf-Gw for emacs-devel@gnu.org; Thu, 10 Jan 2008 01:46:15 -0500 Original-Received: from lefty.soaustin.net ([66.135.55.46] helo=mail.soaustin.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JCrB8-0000f8-W9 for emacs-devel@gnu.org; Thu, 10 Jan 2008 01:46:15 -0500 Original-Received: by mail.soaustin.net (Postfix, from userid 502) id C4E278C12D; Thu, 10 Jan 2008 00:46:12 -0600 (CST) Content-Disposition: inline In-Reply-To: <20080110042340.GB12523@kobe.laptop> User-Agent: Mutt/1.5.13 (2006-08-11) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-Mailman-Approved-At: Thu, 10 Jan 2008 03:17:44 -0500 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:86686 Archived-At: 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