From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: Bug tracking Date: Tue, 15 Jun 2004 03:36:37 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040614091950.7D88.JMBARRANQUERO@wke.es> <20040614232525.A694.LEKTU@mi.madritel.es> Reply-To: ttn@glug.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1087307455 14429 80.91.224.253 (15 Jun 2004 13:50:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 15 Jun 2004 13:50:55 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jun 15 15:50:43 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BaEKp-0002PR-00 for ; Tue, 15 Jun 2004 15:50:43 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BaEKp-0000xQ-00 for ; Tue, 15 Jun 2004 15:50:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BaELl-0003O4-N7 for emacs-devel@quimby.gnus.org; Tue, 15 Jun 2004 09:51:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BaELc-0003Nu-3k for emacs-devel@gnu.org; Tue, 15 Jun 2004 09:51:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BaELa-0003NK-57 for emacs-devel@gnu.org; Tue, 15 Jun 2004 09:51:31 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BaELZ-0003NG-TL for emacs-devel@gnu.org; Tue, 15 Jun 2004 09:51:29 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BaEKN-0005cn-2Q for emacs-devel@gnu.org; Tue, 15 Jun 2004 09:50:15 -0400 Original-Received: from [151.38.172.9] (helo=surf.glug.org) by mx20.gnu.org with esmtp (Exim 4.34) id 1BaCwk-00057m-7a for emacs-devel@gnu.org; Tue, 15 Jun 2004 08:21:51 -0400 Original-Received: from ttn by surf.glug.org with local (Exim 3.35 #1 (Debian)) id 1Ba2sP-0007g9-00; Tue, 15 Jun 2004 03:36:37 +0200 Original-To: Juanma Barranquero In-reply-to: <20040614232525.A694.LEKTU@mi.madritel.es> (message from Juanma Barranquero on Mon, 14 Jun 2004 23:36:56 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:24992 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24992 From: Juanma Barranquero Date: Mon, 14 Jun 2004 23:36:56 +0200 You lost me there. My primary interest is user interface, which is what makes or breaks the success of a bug tracker. Users must be able to enter bug reports easily, and developers must be able to see what's done and what's waiting, who's doing what, etc. also easily. Whether the data is in cuneiform tablets or tachyonic particles oscillating between alternate universes is an implementation detail. a system designer might say the user interface is also an implementation detail (anything but the block diagram could be considered so). my primary interest is in emulating the thought patterns of (good) system designers. But in fact, and contrarily to many things heard in this thead, I'm specifically proposing to develop *nothing* (or at least, almost nothing), so data representation is an issue for the software already existing out there, not for me. I'm hearing about using text files and developing modes to manage and display that information, and I wonder, who's going to implement it? Because I know I'm not (although I will use whatever we have, if someone invests the effort in developing it). if the design is clean and approachable, the implementation will tend to happen w/o too much pushing. i was hoping you would propose an abstract-ish design in the form of a big block diagram, taking into consideration the wide-ranging requirements mentioned thus far, that we could clean up and post somewhere. the major effort is in conceiving the big block diagram, IMHO; code will follow, naturally. First, though, we'd have to answer whether we want a bug tracker (as I proposed), a pending-and-future-issues planner (as I think Richard wants), both or none. Personally I find little use in the planner, a text file (with no custom elisp development) is fine. But a bug tracker, oh yes, I strongly think this would be good for the project. perhaps these are specializations that can be deferred? thi