From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?Q?=D3scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Why Emacs needs a modern bug tracker Date: Sat, 05 Jan 2008 01:44:16 +0100 Message-ID: References: <20080104164454.0A4BD830697@snark.thyrsus.com> <20080104232514.GB2735@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199493880 15641 80.91.229.12 (5 Jan 2008 00:44:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2008 00:44:40 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 01:45:01 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 1JAx9n-0000vy-Nu for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 01:45:00 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAx9R-00019t-4E for ged-emacs-devel@m.gmane.org; Fri, 04 Jan 2008 19:44:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JAx9N-00019g-Nh for emacs-devel@gnu.org; Fri, 04 Jan 2008 19:44:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JAx9M-00017a-Fb for emacs-devel@gnu.org; Fri, 04 Jan 2008 19:44:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAx9M-00017N-2x for emacs-devel@gnu.org; Fri, 04 Jan 2008 19:44:32 -0500 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JAx9L-0007bS-Lr for emacs-devel@gnu.org; Fri, 04 Jan 2008 19:44:32 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JAx9G-0005BQ-Ho for emacs-devel@gnu.org; Sat, 05 Jan 2008 00:44:26 +0000 Original-Received: from 169.red-81-35-77.dynamicip.rima-tde.net ([81.35.77.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Jan 2008 00:44:26 +0000 Original-Received: from ofv by 169.red-81-35-77.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Jan 2008 00:44:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 112 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 169.red-81-35-77.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (windows-nt) Cancel-Lock: sha1:E0/arD3bytKbh/jMjzAqxcDXg0I= X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:86097 Archived-At: Alan Mackenzie writes: [snip] >> 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. X done badly is worse than not having X... this is a general justification for rejecting change, not for rejecting bad ideas. >> 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 usual spam-detection schemes works for bug submissions and every serious bug-tracking system supports them. There is no reason for having more spam on the bug tracker than on this same mailing list. For the required human intervention, I volunteer. [snip] > 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. Most fields are automatically filled by Emacs. > 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". Sure, this is what we can expect from Emacs' corporate culture . Please be serious. There are no pointy-haired bosses here. [snip] >> 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. [snip] I don't use point-and-click for filling web forms, keyboard works fine, thanks. See available solutions for your web browser. Even for filling text areas I use an utility that makes possible and convenient to do it with my favourite text editor. Really, it not as bad as you paint it, once you (and not your pointy-haired boss) are the one that controls the tools. > Like Richard said in another thread, we all have different proclivities, > and we _CHOOSE_ our tools to suit us. If we all have different proclivities, why we all use the same tools for developing Emacs? I guess this is because of consensus. You use CVS, although others may prefer Arch, and so on. The issue here is: are there better options? something that enhances our *overall* sense of gratification? See, DVCSs are great for working off-line, plus lots of other major advantages over CVS. However, the proposal had a cold response by precisely those who valuates working offline as essential. After reading RMS' replies I'm sure that if he works with a decent DVCS for a month, he will reject going back to CVS. Seriously. Please keep an open mind. > 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. Expressions like "suffocatingly constrained web interface" are too negative. Maybe you had a bad experience. I only can say that I wish Emacs' Customize forms were more web-form-alike. [snip] > 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. I was thinking about this possibility and concluded that it is not possible to build a decent bug-tracking system using only a VCS. The reason is the importance of the user interface, which must be open to everybody, not only for the committers, as PROBLEMS and TODO are now, thus effectively dissuading possible contributions from the outside. Furthermore, a bug-tracking system needs a database and a VCS is not good at that. -- Oscar