From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: One possible bug-tracking system. Date: 20 Jun 2004 07:42:55 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87fz8qxuwg.fsf@floss.red-bean.com> References: <20040620023857.1845.LEKTU@mi.madritel.es> <20040620011728.GA4120@fencepost> <20040620032820.BD4D.LEKTU@mi.madritel.es> <87pt7vxai0.fsf_-_@floss.red-bean.com> <87lliibbwx.fsf@emacswiki.org> Reply-To: kfogel@red-bean.com NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1087758034 19182 80.91.224.253 (20 Jun 2004 19:00:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 20 Jun 2004 19:00:34 +0000 (UTC) Cc: Juanma Barranquero , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Jun 20 21:00:24 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 1Bc7YG-0004vH-00 for ; Sun, 20 Jun 2004 21:00:24 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Bc7YF-0002mf-00 for ; Sun, 20 Jun 2004 21:00:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bc7ZS-0007OU-Pa for emacs-devel@quimby.gnus.org; Sun, 20 Jun 2004 15:01:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Bc7ZP-0007OJ-M4 for emacs-devel@gnu.org; Sun, 20 Jun 2004 15:01:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Bc7ZN-0007Nu-NB for emacs-devel@gnu.org; Sun, 20 Jun 2004 15:01:35 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bc7ZN-0007Nr-Kt for emacs-devel@gnu.org; Sun, 20 Jun 2004 15:01:33 -0400 Original-Received: from [207.115.63.73] (helo=pimout5-ext.prodigy.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Bc7Xo-00067O-CM for emacs-devel@gnu.org; Sun, 20 Jun 2004 14:59:56 -0400 Original-Received: from floss.red-bean.com (adsl-65-42-91-60.dsl.chcgil.ameritech.net [65.42.91.60]) by pimout5-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i5KIxi4G102108; Sun, 20 Jun 2004 14:59:44 -0400 Original-Received: from kfogel by floss.red-bean.com with local (Exim 3.34 #1 (Debian)) id 1Bc1ex-0005o1-00; Sun, 20 Jun 2004 07:42:55 -0500 Original-To: Alex Schroeder Emacs: more than just a Lisp interpreter, a text editor as well! In-Reply-To: <87lliibbwx.fsf@emacswiki.org> Original-Lines: 92 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:25125 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25125 Alex Schroeder writes: > Assuming we don't want HTML output and we want simpler input, > wouldn't a file in outline mode be enough? What it lacks is the ability to compose & browse bug summaries organized by severity, assignee(s), search matches, etc. That kind of interface is very important for getting an overview of what's going on and for prioritizing. Each bug needs to be a first class object, with specific meta-data and state associated with it. That could be achieved using outline mode, but probably we'll want better browsing than outline mode affords. I was thinking of a format that is a series of bug entries, something like this: -*- -*- -*- -*- -*- Summary: find-file-noselect fails when used with bleach Id: #73 Severity: LOW | MED | HIGH Priority: LOW | MED | HIGH Reporters: jrandom@example.com Type: DEFECT | ENHANCEMENT | FEATURE | TASK Status: OPEN | STARTED | CLOSED Resolution: (none) | FIXED | INVALID | WONTFIX | DUPLICATE | WORKSFORME Accepted by: some@emacs.developer Emacs info: In GNU Emacs 21.3.50.1 (i686-pc-linux-gnu) of 2004-05-16 on mymachine.example.com Important settings: value of $LC_ALL: nil [... etc, etc ...] Description: M-x find-file-noselect errors when invoked with bleach. But it is documented to work -- it's supposed to remove all color from the file contents if bleach is non-nil. I think the problem can be traced to this line in files.el: ... -*- -*- -*- -*- -*- Summary: blah blah blah Id: #74 Severity: LOW | MED | HIGH Priority: LOW | MED | HIGH Reporters: someone-else@example.com Type: DEFECT | ENHANCEMENT | FEATURE | TASK Status: OPEN | STARTED | HAVE_PATCH | CLOSED Resolution: (none) | FIXED | INVALID | WONTFIX | DUPLICATE | WORKSFORME Accepted by: another@emacs.developer Emacs info: [... etc, etc ...] Description: [... etc, etc ...] The idea is we'd have functions for browsing this file in summary form: M-x bugz-browse-all M-x bugz-browse-open M-x bugz-browse-goto-bug M-x bugz-browse-matching That last one would take a field name (or "any") and a string to match, and show all bugs matching the string. By "show", I mean a separate buffer with optimized movement commands, showing each bug that matches the request. Defects would have a red background on their Type field, so they are immediately obvious, and so on. Once you've selected a bug, you can jump to it in the master bugs file (narrowed) with one keystroke, of course, so that changing a bug's status is just a matter of jumping (either from summary buffer, or via `bugz-browse-goto-bug') and editing the master file. Metadata can also be edited directly in the summary buffer, of course. There would be a function `bugz-attach-mail' and a variable `bugz-attach-mail-func'. The variable's value is a function appropriate for each mail reader in Emacs. `bugz-attach-mail' would prompt for a bug ID number. While reading an email relevant to some bug, you invoke `bugz-attach-mail', and it appends that email to an mbox file in a dedicated subdirectory for that bug, a path which is known to the master bugs file. (That's the best I can think of right now for an email tracking system. We're rather constrained by the requirement that all the data be in the working copy. However, we could eventually set up a system that listens for emails with special subjects, and automatically files them in the right place and commits them.) Of course, all this is easy to say. Who's going to code it? I am too swamped right now to do it :-(. But I hope maybe someone else will agree that this approach has promise and whip something up. Or maybe there's a system that does something like this already? -Karl