unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Thien-Thi Nguyen <ttn@giblet.glug.org>
Cc: rlb@defaultvalue.org, evan@glug.org, guile-devel@gnu.org
Subject: Re: Handling BUGS.
Date: Sun, 24 Mar 2002 11:31:17 -0800	[thread overview]
Message-ID: <E16pDi1-0006Jb-00@giblet> (raw)
In-Reply-To: <87wuw2gk81.fsf@zagadka.ping.de> (message from Marius Vollmer on 24 Mar 2002 14:37:34 +0100)

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 24 Mar 2002 14:37:34 +0100

   Yes, I was referring to Rob's plan to move resolved bugs into a
   different directory.  When we use one file per BUG, we should not put
   them into different directories depending on their state.  This would
   be nice for a quick overview, but as you say, we can get this with
   some simple tools that would also allow for more a flexible
   categorization.

ok i understand now.  yes, agreed.  it's the old "how to represent
attributes -- inside or outside" question.

   This is nice.  What about a Gnus mail backend that works on the bug
   data base? ;-)  (Only half joking..)

eventually Gnus interfaces to all trees, so yeah why not?

   I see that we already have a workbook/bugs directory (thanks!).  What
   about putting the following README into it, as a start:

       [field deinition / documentation]

cool.

       The names of the bug files can be chosen arbitrarily, but must
       start with a lower case letter.  If you don't want to use a
       symbolic name, use a name of the form "bug-<n>" where <n> is the
       next unused number.  these names are used to refer to bugs from
       within the description of other bugs, and in discussions, so it
       helps to use mildly descriptive names.

maybe something like bug-000.no-bugs-database ?  we also need to ask
if/how a bug-000.scm (that would exercise the bug) are to be referenced
and/or included in the database.  keeping such code in the databse might
be less work in the long run (it would be easy to extract them into some
regression/ directory for nightly tests).  maybe something like:

  test-cases: ("bug-000.1.scm" "bug-000.2.scm" ...)

       Meta information about the bug tracking system (like this README
       file) should be put into files that start with a upper case letter.

yeah i like easy-to-understand conventions that "ls" handles
automatically.  :->

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


  reply	other threads:[~2002-03-24 19:31 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-21 17:12 Handling BUGS Rob Browning
2002-03-21 23:09 ` Neil Jerram
2002-03-22  0:54   ` Rob Browning
2002-03-22  9:03     ` Neil Jerram
2002-03-22  6:35 ` Thien-Thi Nguyen
2002-03-22  9:14   ` Neil Jerram
2002-03-22 14:25   ` Rob Browning
2002-03-22 19:32     ` Thien-Thi Nguyen
2002-03-22 17:40 ` Evan Prodromou
2002-03-22 19:13   ` Thien-Thi Nguyen
2002-03-22 19:40     ` Evan Prodromou
2002-03-22 20:08       ` Thien-Thi Nguyen
2002-03-22 20:34         ` Evan Prodromou
2002-03-22 21:41           ` Thien-Thi Nguyen
2002-03-22 22:33             ` Rob Browning
2002-03-23  0:53               ` Thien-Thi Nguyen
2002-03-23 12:14                 ` Marius Vollmer
2002-03-23 14:12                   ` Rob Browning
2002-03-23 14:59                     ` Rob Browning
2002-03-24 19:14                     ` Marius Vollmer
2002-03-23 21:43                   ` Thien-Thi Nguyen
2002-03-24 13:37                     ` Marius Vollmer
2002-03-24 19:31                       ` Thien-Thi Nguyen [this message]
2002-03-24 20:40                         ` Marius Vollmer
2002-03-24 21:13                           ` Rob Browning
2002-03-24 22:00                             ` Marius Vollmer
2002-03-25  3:57                               ` Rob Browning
2002-03-25  8:32                           ` Thien-Thi Nguyen
2002-03-25 21:05                             ` Marius Vollmer
2002-03-25 21:34                               ` Thien-Thi Nguyen
2002-03-25 22:31                                 ` Marius Vollmer
2002-03-25 23:22                                   ` Thien-Thi Nguyen
2002-03-25 23:39                                   ` Thien-Thi Nguyen
2002-03-22 20:34         ` Thien-Thi Nguyen
2002-03-22 22:31       ` Rob Browning

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E16pDi1-0006Jb-00@giblet \
    --to=ttn@giblet.glug.org \
    --cc=evan@glug.org \
    --cc=guile-devel@gnu.org \
    --cc=rlb@defaultvalue.org \
    --cc=ttn@glug.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).