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: Fri, 4 Jan 2008 23:25:14 +0000 Message-ID: <20080104232514.GB2735@muc.de> References: <20080104164454.0A4BD830697@snark.thyrsus.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199488577 1659 80.91.229.12 (4 Jan 2008 23:16:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Jan 2008 23:16:17 +0000 (UTC) Cc: 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 00:16:36 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 1JAvmF-0001sU-Jc for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 00:16:36 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAvls-0004ar-UG for ged-emacs-devel@m.gmane.org; Fri, 04 Jan 2008 18:16:12 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JAvlo-0004ac-RQ for emacs-devel@gnu.org; Fri, 04 Jan 2008 18:16:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JAvln-0004aQ-5y for emacs-devel@gnu.org; Fri, 04 Jan 2008 18:16:07 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAvln-0004aN-0C for emacs-devel@gnu.org; Fri, 04 Jan 2008 18:16:07 -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 1JAvlm-0003Gd-G5 for emacs-devel@gnu.org; Fri, 04 Jan 2008 18:16:06 -0500 Original-Received: (qmail 41954 invoked by uid 3782); 4 Jan 2008 23:16:04 -0000 Original-Received: from acm.muc.de (p57AF4DA6.dip.t-dialin.net [87.175.77.166]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Sat, 05 Jan 2008 00:16:02 +0100 Original-Received: (qmail 6476 invoked by uid 1000); 4 Jan 2008 23:25:14 -0000 Content-Disposition: inline In-Reply-To: <20080104164454.0A4BD830697@snark.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:86094 Archived-At: Hi, Eric! On Fri, Jan 04, 2008 at 11:44:54AM -0500, Eric S. Raymond wrote: [ .... ] > Now I consider Emacs: 1100K lines, a COCOMO estimate of over 328 years, > and no issue database. I think I understand much better now why the > team has only been able to ship one release in five years. Trying to > converge on a releasable state with as poor a view of the Emacs bug > load as we have must be damn near impossible. I think you've got a case, but you're overstating it. Each (major) Emacs release goes through exhaustive testing, and this takes many, many months. I think RMS can and does keep well abreast of the bug status, even though I wouldn't be able to with just email. I don't think we want to do several major releases per year. Perhaps once every two years. Upgrading, for typical users, is nerve-wracking, and costs time and energy. They want to do it as little as possible, or never. For industrial programmers who are behind schedule (i.e. all of them), they need a strong reasons before they will upgrade. > Only...I suspect you (the team) don't know how poor your view is, > because you've never had a good view of a bug collection at your scale > to contrast it with. (To be fair, it's only in the last two or three > years that I have grasped this myself.) I've worked many years in industry. Bug databases done badly are worse, much worse, than our email archive. > Beside the searchability problems with pile-of-emails organization > is another one; accepting emailed reports makes even *collecting* > well-structured information about bugs highly problematic. Talking of which: however we collect bug reports, we will need moderation of some sort to exclude spam. Can we take it that this is a solved problem? > The good thing about bug-tracker web forms from a developer point of > view isn't really that they're web, it's that they're *forms*. You can > channel your users into identifying the platform they're running on, > the preceived bug severity, and half a dozen other search keys. 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. 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". > In email, users will embed these things in running text and expect > you to parse them by eyeball. Which means if you want a database > of bug reports instead of a mere pile of them, you get to re-enter > each one. Yuck. In practice, nobody is ever willing to do this. > This means that email bug entry needs to be deprecated, redirecting > people to a web form (or, in the special case of Emacs, a simulated > form in emacsbug). Had you not wondered why Emacs is about the only > major project left that *isn't* trying to push its users onto an issue > tracker? This is why... 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. > To sum up the back-end argument, the reason I want Emacs to have a real > bug tracker is for the database it will build, so we'll have a better > view of our bugs. From this (developer) point of view it's accidental > rather than essential that the all the good ones built in the last > decade are Web-facing. > Now let's talk about user experience. > *This* is where browser-centric interfaces become important. I > know from recent experience on Wesnoth and elsewhere that most users > actually prefer using a well-designed web-based bug tracker to > emailing bug reports. For them, it *is* about the browser UI. They > find the structure and the sense of familiarity reassuring. Right. Eric, unplug your mouse and tell me how well-designed and reassuringly familiar it is then. I'm required to drive a bug database (and other process abortions) by a grotty point and click web interface 8 hours per working day at my day job, and I'm damned if I'm going to come home and spend my playing time doing the same. Discarding spam from a mailman moderation web interface (which I do for help-gnu-emacs and bug-gnu-emacs) is about as far as I want to go with point and click, and even that's only tolerable because it's so mindless. Like Richard said in another thread, we all have different proclivities, and we _CHOOSE_ our tools to suit us. By the very nature of our product, we care deeply about the tools we use. Perhaps this is the real reason Emacs is still using email for dealing with bugs, rather than a bug tracker with a suffocatingly constrained web interface. > Fortunately, most modern issue trackers allow you to feed all the > submissions and followon comments to a designated buglist. So, if and > when we activate one, you old-schoolers will be able to keep your Gnus > readers. 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. 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. -- Alan Mackenzie (Nuremberg, Germany).