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 12:23:10 +0000 Message-ID: <20080105122310.GB3014@muc.de> 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=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1199535252 6107 80.91.229.12 (5 Jan 2008 12:14:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2008 12:14:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 13:14:31 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 1JB7v2-0001lY-KF for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 13:14:28 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JB7uf-0004yY-V8 for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 07:14:05 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JB7uc-0004vw-1B for emacs-devel@gnu.org; Sat, 05 Jan 2008 07:14:02 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JB7ub-0004uD-3x for emacs-devel@gnu.org; Sat, 05 Jan 2008 07:14:01 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JB7ub-0004u2-0C for emacs-devel@gnu.org; Sat, 05 Jan 2008 07:14:01 -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 1JB7ua-0001Zn-Mi for emacs-devel@gnu.org; Sat, 05 Jan 2008 07:14:01 -0500 Original-Received: (qmail 32605 invoked by uid 3782); 5 Jan 2008 12:13:58 -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 13:13:56 +0100 Original-Received: (qmail 4121 invoked by uid 1000); 5 Jan 2008 12:23:10 -0000 Content-Disposition: inline In-Reply-To: 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:86144 Archived-At: Afternoon, Óscar! On Sat, Jan 05, 2008 at 01:44:16AM +0100, Óscar Fuentes wrote: > Alan Mackenzie writes: [ .... ] > > 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. Well.... Bug databases in companies tend to be done badly. Some of the forces that cause that might be present in free projects, so we need to be very careful. [ .... ] > >> 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. I've never found a web browser good for anything other than browsing the web. I find filling in web forms so painful that I never do it unless I can't avoid it. Maybe getting the fields editable by Emacs would make it tolerable. We'll see. > 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? Each of us have our own .emacs, some use a GUI, some text terminals, we all use different mail clients, ..... > 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? Supremely important is that the new tools must be customizable to suit the way ANY of us work. > 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. Probably, so will I. > Please keep an open mind. I'm trying to be a counter-balancing force against those advocating massive change. > > 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. I've had nothing but bad experience using web interfaces for anything but web browsing (in its narrow sense). "Suffocatingly constrained" accurately describes what I feel about these interfaces. A good comparison is that of Info documentation vs. the reading the same manual as html. I don't want to be forced to use a web interface, even a keyboard driven one, for reporting bugs. I can't be alone. > > 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. OK, VCS access IN ADDITION TO web access. How about that? > Furthermore, a bug-tracking system needs a database and a VCS is not > good at that. That is a good argument for staying with an email based system. ;-( What's the point of a bug system if you have to be online to use it? It kind of cancels out the benefit of a dVCS for our other files. Are you telling me I won't be able to grep a bug-tracking database? If I'm using such a database, I want instant response when I press to look at an item. I want to be able to do M-x occur (or the like) on it, without going through some ghastly GUI interface. I want regexp searching, filtering with a "command line"-like interface (e.g., like mutt has), and so on. And I want the database on my own hard disk, for speed and flexibility. > Oscar -- Alan Mackenzie (Nuremberg, Germany).