From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Gianluca Della Vedova Newsgroups: gmane.emacs.devel Subject: Re: Why Emacs needs a modern bug tracker Date: Fri, 4 Jan 2008 18:38:54 +0000 (UTC) Message-ID: References: <20080104164454.0A4BD830697@snark.thyrsus.com> <200801041833.37632.andreas.roehler@online.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1199472001 13157 80.91.229.12 (4 Jan 2008 18:40:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Jan 2008 18:40:01 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 04 19:40:19 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 1JArSp-0008MZ-JN for ged-emacs-devel@m.gmane.org; Fri, 04 Jan 2008 19:40:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JArST-0005ST-5F for ged-emacs-devel@m.gmane.org; Fri, 04 Jan 2008 13:39:53 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JArRj-0004Uv-U7 for emacs-devel@gnu.org; Fri, 04 Jan 2008 13:39:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JArRi-0004TS-Mh for emacs-devel@gnu.org; Fri, 04 Jan 2008 13:39:07 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JArRi-0004TC-BK for emacs-devel@gnu.org; Fri, 04 Jan 2008 13:39:06 -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 1JArRh-0005Jl-UT for emacs-devel@gnu.org; Fri, 04 Jan 2008 13:39:06 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JArRc-0003Mh-Hr for emacs-devel@gnu.org; Fri, 04 Jan 2008 18:39:00 +0000 Original-Received: from host126-11-dynamic.58-82-r.retail.telecomitalia.it ([82.58.11.126]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Jan 2008 18:39:00 +0000 Original-Received: from gianluca.dellavedova by host126-11-dynamic.58-82-r.retail.telecomitalia.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Jan 2008 18:39:00 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 129 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 82.58.11.126 (Mozilla/5.0 (X11; U; Linux i686; it; rv:1.8.1.11) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/2.0.0.11) 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:86076 Archived-At: Andreas Röhler online.de> writes: > > Am Freitag, 4. Januar 2008 17:44 schrieb Eric S. Raymond: > [ stuff deleted ] > > > > One of the places a real issue database is most concretely useful is when > > you're triaging bugs to close on a release. It is *immensely* helpful > > in making clear what needs to be done and at what point you are > > finished doing it. > > [ stuff deleted ] > > 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. > > > > 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. > > > > 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... > > > > 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. > > > > Gianluca makes exactly this point in his post. Almost my point. I agree that, IMO, the browser UI is better then email for bug submissions. But I was also referring to the fact emails can get replies that are quite discomforting, if not nasty or rude: Such a kind of response can quickly lead to abandon the mailing list. A web form is perceived to be more anonymous, and closing a "fake" bug report without explanation (because it is not really a bug) is not something that can be taken personally. I don't think the same applies to emails to a mailing list, where the fact that a bug report is bogus is exposed to everybody. Part of my post was also devoted to give some of the benefits of the issue database structure that Eric has clearly described above. [ stuff deleted ] > > 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. > In my blog post (and not in my previous email) I suggested a bug tracker similar to Debian's. It's main advantage, among other bug tracker I know of, is that it can be effectively used by email only. Tipically a bug report is filled on the web (as Eric has suggest it can be emulated via a Emacs form). For each bug report a unique email address is created, and the bug report, as well as any subsequent comments is sent also to such address. The same address can also be used for sending commands for handling the bug: such commands can be something like "close the bug", or "set severity to ..". Since reporting a bug is usually done by a user and not by a developer, I believe that such a bug tracker could easily fit with the current developers' modus operandi. [ stuff deleted ] > > With Richard, principles of developing are more or less > immanent by his decisions and experience. > To keep this waste universe of code running smoothly > will afterwards need a lot more of > outspoken rules than now. > If Emacs is adopting a bug tracker some new rules (i.e. what are the possibile severity levels) are necessary. > Concerning the bugtracking: a lot of bugs reported > aren't really one. That can't be changed. What with all > this false bugs in a database? > They can be closed clicking on a button or sending an email with subject "closed". The effort should not be that much than ignoring the email after having read it. > OTOH some severe bugs seem reported from time to time, > but not fixed so far. Will a database change that? > No. But some less severe bugs can be fixed by non-core developers, giving more time for the core developers to work on more important issues. And the number/quality of users confirming a bug can help in understanding the actual severity of the bug. > What about some kind of a blackboard, establishing a > hierarchy of important bugs naming a person in charge > for it? > It is one of the purposes on having an issue tracker.