From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Why Emacs needs a modern bug tracker Date: Sat, 5 Jan 2008 11:17:20 +0000 Message-ID: <20080105111720.GA3014@muc.de> References: <20080104164454.0A4BD830697@snark.thyrsus.com> <20080104232514.GB2735@muc.de> <20080105052007.GA27075@thyrsus.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199531317 28295 80.91.229.12 (5 Jan 2008 11:08:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2008 11:08:37 +0000 (UTC) Cc: "Eric S. Raymond" , emacs-devel@gnu.org To: "Eric S. Raymond" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 12:08:56 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 1JB6tb-0004KL-6W for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 12:08:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JB6tE-0004eu-Hy for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 06:08:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JB6sx-0004ZV-Ex for emacs-devel@gnu.org; Sat, 05 Jan 2008 06:08:15 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JB6sw-0004Z6-Jh for emacs-devel@gnu.org; Sat, 05 Jan 2008 06:08:14 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JB6sw-0004Z1-7S for emacs-devel@gnu.org; Sat, 05 Jan 2008 06:08:14 -0500 Original-Received: from colin.muc.de ([193.149.48.1] helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JB6sv-0000EP-Ng for emacs-devel@gnu.org; Sat, 05 Jan 2008 06:08:14 -0500 Original-Received: (qmail 15850 invoked by uid 3782); 5 Jan 2008 11:08:09 -0000 Original-Received: from acm.muc.de (p57AF7576.dip.t-dialin.net [87.175.117.118]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Sat, 05 Jan 2008 12:08:07 +0100 Original-Received: (qmail 3292 invoked by uid 1000); 5 Jan 2008 11:17:21 -0000 Content-Disposition: inline In-Reply-To: <20080105052007.GA27075@thyrsus.com> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 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:86139 Archived-At: Hi, Eric! On Sat, Jan 05, 2008 at 12:20:07AM -0500, Eric S. Raymond wrote: > Alan Mackenzie : [ .... ] > > I've worked many years in industry. Bug databases done badly are > > worse, much worse, than our email archive. > Granted. But we have the talent and tools to do it right. OK, we're agreed! There was something in your posting which suggested the notion that merely using such tools would be the Right Thing. We need to use them well, too. [ .... ] > > If they're pure web, I doubt they'll be accepted by the hackers here, > > who're accustomed to Emacs-quality interfaces. Whatever we decide on > > must be usable from a normal Emacs buffer. > There's emacs-bug to be hacked. And one of our listmembers has > already noted that the Debian tracker can be driven by email. What is "emacs-bug"? I think I'm missing some context somewhere. > > Also, the fields in these forms must be kept under as tight control > > as a camp fire in a drought stricken forest. 4 or 5 fields are OK. > > 8 to 10 are pushing the boundary. Let a QA department into the > > works, and before you know it you've got upwards of 100 largely > > meaningless fields, so that said QA "can accurately monitor the > > trends and problems of the developers and tune the company's > > processes accordingly". > This is true. You'll be reassured, perhaps, to know that the > evolutionary direction in bug trackers has been to simplify, simplify, > simplify. The original Bugzilla was exactly the sort of nightmare you > describe, and I refused to have anything to do with it. More recent > ones like the Ubuntu and Gna! bug trackers are quite lightweight and > pleasant by comparison. The best (proprietary) bug tracker I ever used had fields only for things like person creating the entry, status (open/fixed/rejected), customer, severity, urgency. Then it had free text areas for describing the bug. > > I disagree. An email bug entry system is necessary, and should > > perhaps be the preferred method, with a web form as an alternative. > > This email will of course be structured. M-x report-emacs-bug or C-c > > C-b (in a CC Mode buffer) could be enhanced easily enough. > Like I said, emacs-bug. It's *unstructured* mail that has to be > deprecated. Deprecated or enhanced? ;-) > > Hmmm. I hope that's not as contumelious as it sounds. That "allow" > > had better be a first class interface, not just a second rate crock > > intended to keep us "outmoded grandads" from moaning. > Write it. Then you'll know it's correct. Fair response. ;-) But the base system has to be one that allows appropriate access. A mail archive allows searching by all of mutt's handy operators. You can even grep the raw mailbox archive (yes, this IS useful, even though you only need to do this occasionally). My fear is that the new bug tracker will be restricted to what its designers thought was "all that you need"; or that I'll have to go through a ghastly point and click "create a query" interface, like I had to yesterday at work. > > How about this suggestion: the bug database should be administered by > > our super-duper new distributed VCS, having its definitive version at > > savannah. Hackers will then update it by committing (?pushing) their > > changes from their own local versions. With these local versions, > > they will have far more usable and flexible facilities than they > > would over a lame http connection. > No good. You're ignoring the *users*. Remember users...you know, he > people the reporting emd of a tracker is actually *for*? They don't > want to futz with some geek's wet dream of "flexibilty". They want web > forms. I wasn't very clear, there. Of course users need web forms, and they will manipulate the database directly. But why can't we have VCS updating, too? This will allow RMS and others to work offline, a very desirable thing. -- Alan Mackenzie (Nuremberg, Germany).