More Bug Stuff

More Bug Stuff

[Evan Prodromou]

OK, so, here's my collected bug file headers list. It gives the header
name, arity (can be 0, 1, or Inf), and a description of what it's
for. Let me know if I'm missing anything here.

* Number (1)

  Identifying number for the bug, as an integer. Ex:

  Number: 12

* Title (1)

  Short descriptive title for the bug. Ex:

  Title: documentation mistakenly defines :autoload argument as expr and not list

* Reported-By (0,1)

  Name and email address of person who reported the bug, in
  angle-bracket format. Ex:

  Reported-By: Evan Prodromou <evan@glug.org>

* Date-Reported (0,1)

  Date the bug was reported. Ex:

  Date-Reported: Sun, 24 Mar 2002 11:31:17 -0800
  Date-Reported: 24 Mar 2002

  All dates must either be in the above "standard" format, or in the
  format:

            dd Mon YYYY

* Status (1)

  Status of the bug, in the format:

         status-val [(comment)]

  Here, status-val is one of: New, Unassigned, Assigned, Closed,
  Suspended, and comment is an optional comment. 

  Status: New (received from bug-auto@gnu.org)
  Status: Suspended (unable to replicate error)
  Status: Closed

* Priority (0,Inf)

  Priority of the bug, in this format:

           priority-val [[version=[version no]] (comment)]

  where priority-val is an integer between 1 and 10, and lower
  numbers are higher priority. The version number is the Guile branch
  or version where this is supposed to be fixed. For example, if a bug
  is of high priority to fix in 1.6, but not so high for 1.4, then the
  Priority headers would be:

  Priority: 8 version=1.4 (not severe enough to warrant work)
  Priority: 2 version=1.6 (crucial for release; talk to rlb)

  Priorities should be unique for a version.

* Severity (0,1)

  How severe the bug is, in terms of what it does to the user. Field
  is:

        severity-val [(comment)]

  Where severity-val is one of:
  
        Wibni (meaning "Wouldn't it be nice if...")

        Theoretical (such as "Buffer overflow possible in guile-readline to
                     get root")

        Nuisance (such as "There's no documentation on this function, so I
                  had to experiment with it")

        Minor (such as "It doesn't work as advertised")
        
        Major (such as "It does damage")
        
        Fatal (such as "Guile killed my dog")

  ...and comment is an optional comment.

  For example:

  Severity: Nuisance (misspelling)
  Severity: Major (Memory leak)
  Severity: Minor
  Severity: Fatal (dumps core)

  NOTE that Priority and Severity are loosely coupled -- things that
  are more severe usually will have a high priority, but not
  necessarily. For example, updating the version string for a release
  is a high priority task, but it's not particularly severe (it'd be a
  nuisance). A bug that randomly causes backup tape explosions in the
  TI-99/4 port of Guile might have high severity, but a low priority.

* Affects-Version (0,Inf)

  Versions of Guile affected by the bug.

  Affects-Version: 1.4
  Affects-Version: 1.6.1
  Affects-Version: 1.7

* Assigned-To (0,1)

  Name and email address of the person this bug is assigned to. Ex:

  Assigned-To: Marius Vollmer <mvo@zagadka.ping.de>

* Date-Fixed (0,Inf)

  Date the bug was fixed, in format:

       date-string version=vno

  Can be multiple if fixed in different branches. vno is the release
  version number that the fixed version should be available. 

  Example:

  Date-Fixed: Sun, 24 Mar 2002 11:31:17 -0800 version=1.5.7
  Date-Fixed: 05 Dec 1999 version=1.7.1
  Date-Fixed: 12 Apr 2001 version=1.4.1

~ESP

-- 
Evan Prodromou
evan@glug.org

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

Re: More Bug Stuff

[Marius Vollmer]

Evan Prodromou <evan@glug.org> writes:

> OK, so, here's my collected bug file headers list. It gives the header
> name, arity (can be 0, 1, or Inf), and a description of what it's
> for. Let me know if I'm missing anything here.
> 
> * Number (1)

Do we need a number?  I'd rather go with a symbolic name.  Numbers are
so, umm, 'C'.

> * Title (1)

Why "Title"?  I prefer "Summary" for this.

> * Reported-By (0,1)
> 
>   Name and email address of person who reported the bug, in
>   angle-bracket format. Ex:

Do we need to restrict us to the angle bracket format?  What about
allowing any RFC2822 mailbox?

>   All dates must either be in the above "standard" format, or in the
>   format:
> 
>             dd Mon YYYY

I'd rather use the ISO format YYYY-MM-DD here.  Do we need a time?

> * Priority (0,Inf)

Again, do we need hard numbers for this?  In general, I think it will
be mostly arbitrary what priority number is assigned to a bug.
Identifying critical bugs, and distinguishing bugs from wishlist items
is important, tho.  We can use Severity for this.

> * Severity (0,1)
> 
>   How severe the bug is, in terms of what it does to the user. Field
>   is:

What about using Debian's list of severities:

    critical 

     makes unrelated software on the system (or the whole system)
     break, or causes serious data loss, or introduces a security hole
     on systems where you install the package.

    grave 

     makes the package in question unuseable or mostly so, or causes
     data loss, or introduces a security hole allowing access to the
     accounts of users who use the package.

    serious 

     is a severe violation of Debian policy (that is, it violates a
     "must" or "required" directive), or, in the package maintainer's
     opinion, makes the package unsuitable for release.

    important 

     a bug which has a major effect on the usability of a package,
     without rendering it completely unusable to everyone.  normal the
     default value, applicable to most bugs.

    minor 

     a problem which doesn't affect the package's usefulness, and is
     presumably trivial to fix.

    wishlist 

     for any feature request, and also for any bugs that are very
     difficult to fix due to major design considerations.

    fixed 

     for bugs that are fixed but should not yet be closed. This is an
     exception for bugs fixed by non-maintainer uploads. Note: the
     "fixed" tag should be used instead.

    Certain severities are considered release-critical, meaning the
    bug will have an impact on releasing the package with the stable
    release of Debian. Currently, these are critical, grave and
    serious.

>   NOTE that Priority and Severity are loosely coupled -- things that
>   are more severe usually will have a high priority, but not
>   necessarily. For example, updating the version string for a release
>   is a high priority task, but it's not particularly severe (it'd be a
>   nuisance).

Are we talking about tasks here as well, in addition to bugs?  For
tasks, priority makes more sense.

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

Re: More Bug Stuff

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 25 Mar 2002 00:03:00 +0100

   Are we talking about tasks here as well, in addition to bugs?  For
   tasks, priority makes more sense.

bugs can result in tasks (like fixing them), and not all tasks are
bug-related.  over time tasks that encounter bugs become bug-related.
presumably people might think it's a good idea to scan the bug list to
see which bugs relate to work in progress, and adding info to the bug db
whenever something interesting occurs might help fix bugs faster, and
DTRT.

so to me these two areas can be better managed separately.  bugs db
should be descriptive and avoid being prescriptive.  referring to a task
from a bug header is already supported.

task prioritization is undocumented mostly because everyone (human) is
motivated differently when they look at any set of tasks.  it is a
personal matter which some may never be comfortable in disclosing.  more
basically, even knowing one's own motivations is difficult sometimes.

probably we can come to rough consensus (as we go along, and enough to
get stuff done) at which time someone should write tasks/TRIAGE.  (a
bugs/TRIAGE is a good idea too.)  perhaps we can borrow further from
debian.

after some thought i believe one dir per bug is a better overall fit.
sorry about being overhasty.  every other approach invents weird syntax
(like the one we're leaving) to forget and screw up.  [jobs clones
guffaw "bundles" into their grey cubes.]

on the other hand, single file at top is simple and here.  so really, my
proposal (now -- please ignore previous) comes down to:

        N  -- the rfc822 for bug N
        .N -- the directory w/ all of bug N's related files;
              may be empty or absent

in the headers, this would add required header:

	bug-stuff-dir: .N

under .N things can be named in regular ways, such as "test-case-1.scm"
or "why-i-must-rant-against-this-bug" or "rfc822" (symlink).  the naming
of these files can be conventionalized later and w/o overmuch regard to
the actual bug number.  programs that munge these files are accordingly
lightened.  programs that munge bug sets need to stay informed w/
`bug-stuff-dir' but that's just another header (already done).

thi

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

Re: More Bug Stuff

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> on the other hand, single file at top is simple and here.  so really, my
> proposal (now -- please ignore previous) comes down to:
>
>         N  -- the rfc822 for bug N
>         .N -- the directory w/ all of bug N's related files;
>               may be empty or absent
>
> in the headers, this would add required header:
>
> 	bug-stuff-dir: .N
>
> under .N things can be named in regular ways, such as "test-case-1.scm"
> or "why-i-must-rant-against-this-bug" or "rfc822" (symlink).  the naming
> of these files can be conventionalized later and w/o overmuch regard to
> the actual bug number.  programs that munge these files are accordingly
> lightened.  programs that munge bug sets need to stay informed w/
> `bug-stuff-dir' but that's just another header (already done).

I really don't like the idea of hidden directories with potentially
critical information.  If we are going to have per-bug directories
could we choose an arrangement that sorts a bug and all its attendant
data together in an ls listing?  I don't have strong prefs, but as an
random place to start, why not:

  N-info
  N-dir/

ls does the right thing, and you can ignore all the -dir files if you
want to with a simple "grep -v", or even "ls *-[^d]*" or similar, and
you can make sure to copy all of a bug's related info via "cp -a N-*
dest".

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: More Bug Stuff

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Mon, 25 Mar 2002 09:48:08 -0600

     N-info
     N-dir/

sounds good to me.  i think we agree that top-level file and subdir of
regularly-named related files can be easy to work with.  [JCG "resource
fork" ITC. :-]

thi

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

Re: More Bug Stuff

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> on the other hand, single file at top is simple and here.  so really, my
> proposal (now -- please ignore previous) comes down to:
> 
>         N  -- the rfc822 for bug N
>         .N -- the directory w/ all of bug N's related files;
>               may be empty or absent

What I have now put into workbook/bugs/README is this

          N      --  the rfc822-look-a-like for bug N, where N can be a
                     number or a alphanumeric name and may not contain a "."
          N.ext  --  A file or directory related to bug N.
                     "ext" can be anything.

> in the headers, this would add required header:
> 
> 	bug-stuff-dir: .N

Why required?


Here is the README as it stands now.  The list of headers is not
really meant to be complete, but should be enough for a start.  I'll
start to move the HEAD BUGS file into the new format now.


    This directory is the Guile bug data base.

    It contains one file per bug with a simple, mail-message like format.
    Each file starts with a number of header lines in the form

         field-name: field-value

    where 'field-name' contains no whitespace and is compared
    case-insensitive.  'field-value' can be continued in the next line by
    using a '\' as the last character of the current line.  The header is
    separated from the body by a blank line.  The body is the rest of the
    file.  There is no limit on the length of a line.

    The following header fields are defined.  They are optional except
    when noted.  Also, specific fields can be present more than once,
    except when noted.

      Summary: <text>

        A one-line summary of the bug.  Mandatory.

      Tags: tag1, tag2, ...  

        A comma separated list of symbolic tag names (for example
        release-critical-1.6).  Tags can be used to collect bugs into
        ad-hoc groups.

      Reported: mailbox, yyyy-mm-dd

        The mail address of the reporter, in RFC2822 mailbox format,
        followed by the date of the report, in ISO8601 format.

      Assigned: mailbox, yyyy-mm-dd

        The developer who is working on a fix, and since when.

      Fixed: mailbox, yyyy-mm-dd

        The developer who fixed it, and when.

      Affects: version, version, ...

        A list of branch tags or version numbers of released tar balls
        that are affected by the bug.

    If you need more header fields, please document them here.

    The names of the bug files can be chosen almost arbitrarily.  They
    must start with a lower case letter or a digit and must not contain a
    "."  character.  If you don't want to use a symbolic name, use 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.  Files or directories that are related to a
    bug, like test programs that invoke the bug, should get the name of
    the bug plus a "."-separated extension, like "bug-1.scm".

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

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

Re: More Bug Stuff

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 25 Mar 2002 22:35:56 +0100

	     N.ext  --  A file or directory related to bug N.
			"ext" can be anything.

   > 	bug-stuff-dir: .N

   Why required?

i'm presuming the tool that groks rfc822+subdir can be used for other
things than bugs; bug tracking is just one (simple) application.  i
agree that for bug tracking this kind of thing need not be specified.

thi

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

Re: More Bug Stuff

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 25 Mar 2002 22:35:56 +0100

   Here is the README as it stands now.  The list of headers is not
   really meant to be complete, but should be enough for a start.  I'll
   start to move the HEAD BUGS file into the new format now.

   [...]

looks good!  glad to see bugs import happening.

thi

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

Re: More Bug Stuff

[Marius Vollmer]

Thien-Thi Nguyen <ttn@glug.org> writes:

> looks good!  glad to see bugs import happening.

The first 15 are in!

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

Re: More Bug Stuff

[Evan Prodromou]

>>>>> "MV" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    MV> What I have now put into workbook/bugs/README is this

OK, so, am I to take it that the work I've done on BUGS conversion and
rendering is no longer needed?

I'm just kind of wondering why I spent any time on this if someone
else was actually going to do it anyways. Is there not enough work on
Guile to go around? Or did I just take too long?

~ESP

-- 
Evan Prodromou
evan@prodromou.san-francisco.ca.us

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

Re: More Bug Stuff

[Thien-Thi Nguyen]

   From: Evan Prodromou <evan@glug.org>
   Date: Tue, 26 Mar 2002 18:31:49 -0600

   I'm just kind of wondering why I spent any time on this if someone
   else was actually going to do it anyways. Is there not enough work on
   Guile to go around? Or did I just take too long?

you were too slow on the conversion to parry the impatience of those w/
write privs...  i tried to make a case for waiting but was unsuccessful.
i think bugs/README could use some refinement, but now am not sure if
Marius is willing to delegate that to you fully at all.

there is still room on the rendering side of things.  i'm happy to let
you do this and integrate your work, but i don't speak for anyone else.

Marius: what are your plans?  can you give input to Evan and leave it to
him, or do you need to do the implementation yourself to be comfortable?

thi

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

Re: More Bug Stuff

[Marius Vollmer]

Evan Prodromou <evan@glug.org> writes:

> >>>>> "MV" == Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
>     MV> What I have now put into workbook/bugs/README is this
> 
> OK, so, am I to take it that the work I've done on BUGS conversion and
> rendering is no longer needed?

No, workbook/bugs/ is far from finished.  I rushed it a bit so that we
could use it for organizing the bugs related to the 1.6 release.

Please continue your work, but base it on workbook/bugs/.  The list of
header fields for example, needs some serious review.

You articles here were essential to what has been done up to now.

> I'm just kind of wondering why I spent any time on this if someone
> else was actually going to do it anyways.

I understood it that way that your render-bugs program would be used
to produce many useful and nice 'views' of the bug database.  That job
still needs to be done.

Converting from a flat ASCII file to the bugs/ directory was not
really much work.

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

Re: More Bug Stuff

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> Marius: what are your plans?

My plans were to announce that bugs are no tracked differently, and to
find the places in our scattered docs where we should point to the new
bug database, and fix them.

Then, I'll gather all bugs I have recorded somewhere (mostly on the
list, and in my personal TODO file), and put them into the database.

> can you give input to Evan and leave it to him,

I can do that, see my direct reply to him.

> or do you need to do the implementation yourself to be comfortable?

No, I hope not. :)

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

Re: More Bug Stuff

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 27 Mar 2002 20:09:15 +0100

   My plans were to announce that bugs are no tracked differently, and to
   find the places in our scattered docs where we should point to the new
   bug database, and fix them.

   Then, I'll gather all bugs I have recorded somewhere (mostly on the
   list, and in my personal TODO file), and put them into the database.

here is a related item in TODO:

  - scan mailing list archives for bugs and add them

would it be correct to append '[mvo]' to this?  1.5.6 release triggered
lots of reports, so maybe we can split this task into two parts (for
attack by two people): reports up to, say, 2002-03, and reports after.
what do you think?

   I can do that, see my direct reply to him.

cool.  i'll document this in TODO.

thi

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

Re: More Bug Stuff

[Evan Prodromou]

>>>>> "MV" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    MV> Do we need a number?  I'd rather go with a symbolic name.
    MV> Numbers are so, umm, 'C'.

It's much easier to auto-generate a unique number than a meaningful
unique symbolic name.

    MV> Why "Title"?  I prefer "Summary" for this.

Why worry about header names? "Summary" is fine.

    Me> Name and email address of person who reported the bug, in
    Me> angle-bracket format.

    MV> Do we need to restrict us to the angle bracket format?  What
    MV> about allowing any RFC2822 mailbox?

It makes writing parsers easier. Do you really need the flexibility of
using ANY kind of address header?

    >> All dates must either be in the above "standard" format, or in
    >> the format:
    >> 
    >> dd Mon YYYY

    MV> I'd rather use the ISO format YYYY-MM-DD here.  Do we need a
    MV> time?

Fine. No, I don't think we particularly need a time.

    >> * Priority (0,Inf)

    MV> Again, do we need hard numbers for this?  In general, I think
    MV> it will be mostly arbitrary what priority number is assigned
    MV> to a bug.

It makes it much easier to say things like this: "For the next beta,
we will fix all priority 1 bugs and as many 2 and 3 bugs as we can."
It makes it easier to mentally categorize that 1 bugs are more
important than 8 bugs. Also, it makes it clear that Priority and
Severity are two different things.

I'm a little confused why you say that priority assignment is "mostly
arbitrary". First off, you've set yourself up as the arbitrator, so
that's about right. But I think it's a generally common practice to
prioritize jobs to do with a number between 1 and N, where N is a
small integer. It's entirely subjective -- based on the project's
goals, not on any algorithmically derivable formula.

    MV> Identifying critical bugs, and distinguishing bugs
    MV> from wishlist items is important, tho.  We can use Severity
    MV> for this.

Hurgh. I knew this would come up. Did you read what I wrote about
Severity vs. Priority?

    Me> NOTE that Priority and Severity are loosely coupled -- things
    Me> that are more severe usually will have a high priority, but not
    Me> necessarily. For example, updating the version string for a
    Me> release is a high priority task, but it's not particularly
    Me> severe (it'd be a nuisance).

    MV> Are we talking about tasks here as well, in addition to bugs?
    MV> For tasks, priority makes more sense.

Sorry, I mistakenly used the word "task" here, which seems to have
confused you. What I should have said was "piece of work." If a
release went out with the FSF address misspelled, this would be a low
_severity_ bug, but a high _priority_ one.

Anyways, OK, the rest looks good.

~ESP

-- 
Evan Prodromou
evan@glug.org

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

Re: More Bug Stuff

[Thien-Thi Nguyen]

   From: Evan Prodromou <evan@glug.org>
   Date: Thu, 28 Mar 2002 10:52:45 -0600

   It's much easier to auto-generate a unique number than a meaningful
   unique symbolic name.

if it's not easier it's more fun to write, no?

   It makes writing parsers easier. Do you really need the flexibility of
   using ANY kind of address header?

i don't understand you.  to me, using ANY instead of some other
complicated syntax is the most flexible, for other tools.

   It makes it much easier to say things like this: [...]
   I'm a little confused why you say that priority assignment is "mostly
   arbitrary"[...]

probably mvo means this kind of scheme is fine to set up, but not in the
bugs database.  prioritization is larger in scope than bugs handling and
generally prioritization schemes are never universal (among humans).

this would be a good time to suggest that render-bugs in the future also
handle small writes to the db (rendering it more like "edit-bugs"), such
as maintaining a "priority: ((WHO N) ...)" header.

   Sorry, I mistakenly used the word "task" here, which seems to have
   confused you. What I should have said was "piece of work." If a
   release went out with the FSF address misspelled, this would be a low
   _severity_ bug, but a high _priority_ one.

   Anyways, OK, the rest looks good.

you're overspecifying, dude.  c'mon man!  first get the core done so we
can jump in w/ passing around higher order functions and all that good
stuff.  separate mechanism and policy and post something elegant.
[insert small steps rant.]

(sorry, i have been -er- wafting some vapors of late.)

thi

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

Re: More Bug Stuff

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    Then, I'll gather all bugs I have recorded somewhere (mostly on the
>    list, and in my personal TODO file), and put them into the database.
> 
> here is a related item in TODO:
> 
>   - scan mailing list archives for bugs and add them
> 
> would it be correct to append '[mvo]' to this?

I have ticked all bug reports in my local archives anyway, so I'll
just import those.  I think this will be reasonably complete.

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

Re: More Bug Stuff

[Marius Vollmer]

Evan Prodromou <evan@glug.org> writes:

> >>>>> "MV" == Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
>     MV> Do we need a number?  I'd rather go with a symbolic name.
>     MV> Numbers are so, umm, 'C'.
> 
> It's much easier to auto-generate a unique number than a meaningful
> unique symbolic name.

OK, we can have both.

>     Me> Name and email address of person who reported the bug, in
>     Me> angle-bracket format.
> 
>     MV> Do we need to restrict us to the angle bracket format?  What
>     MV> about allowing any RFC2822 mailbox?
> 
> It makes writing parsers easier. Do you really need the flexibility of
> using ANY kind of address header?

It would make it easier to paste addresses from mails, and we would
have a way to specify a real name.  Do we actually need to parse the
mailbox string for simple tasks?

>     >> * Priority (0,Inf)
> 
>     MV> Again, do we need hard numbers for this?  In general, I think
>     MV> it will be mostly arbitrary what priority number is assigned
>     MV> to a bug.
> 
> It makes it much easier to say things like this: "For the next beta,
> we will fix all priority 1 bugs and as many 2 and 3 bugs as we can."

Yes, but is this a useful thing to say?  This will depend on how
people will assign priorities and whether something gets a "1" or a
"2" will be mostly arbitrary, I think, and consequently what bugs get
fixed for the beta will be arbitrary as well.  If you see it the other
way around, as: "If you want the bug fixed for the next beta, assign
it a priority of 1, else chose some larger number", then it will limit
the meaning of the priority field to one specific task (in this case
the releasing of the next beta).  And after the beta is out, will we
reprioritize the bugs?

Anyway, I don't really need to understand the importance of a priority
field.  We can have it, as long as its optional.

> I'm a little confused why you say that priority assignment is "mostly
> arbitrary".

The numbers themselves don't mean anything, so when you need to chose
a priority for a bug you'll pick a number that you feel expresses your
idea of the bugs priority.  Other people will chose different numbers
although they might want to express the same idea of priority.

> First off, you've set yourself up as the arbitrator, so that's about
> right.

The system needs to work without a central arbiter.

>     MV> Identifying critical bugs, and distinguishing bugs
>     MV> from wishlist items is important, tho.  We can use Severity
>     MV> for this.
> 
> Hurgh. I knew this would come up. Did you read what I wrote about
> Severity vs. Priority?

Yes.

>     Me> NOTE that Priority and Severity are loosely coupled -- things
>     Me> that are more severe usually will have a high priority, but not
>     Me> necessarily. For example, updating the version string for a
>     Me> release is a high priority task, but it's not particularly
>     Me> severe (it'd be a nuisance).

When a release is out with a wrong version number, I would call that
pretty severe!  (The mere task of updating the version number before a
release would not be recorded as a bug.)

>     MV> Are we talking about tasks here as well, in addition to bugs?
>     MV> For tasks, priority makes more sense.
> 
> Sorry, I mistakenly used the word "task" here, which seems to have
> confused you. What I should have said was "piece of work." If a
> release went out with the FSF address misspelled, this would be a low
> _severity_ bug, but a high _priority_ one.

How can it be severe and still have low priority?  It seems I don't
get it.  Anyway, don't let this stop you from adding a optional
priority field.

[ To be super pedantic: a bug can meaningfully have a severity
  associated with it, but no priority.  A bug is the description of an
  existing behavior, but not a description of a piece of work that
  needs to be carried out.

  Each bug has implicitly associated with it the task of fixing it,
  and that task can have a priority.  But this priority is, in my
  view, not really meaningfully expressible with some hard and fast
  number.  I.e., what has low priority for me might have a high
  priority for you.
]

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

Re: More Bug Stuff

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 07 Apr 2002 13:17:49 +0200

   I have ticked all bug reports in my local archives anyway, so I'll
   just import those.  I think this will be reasonably complete.

would you like me to not look at m.l. archives 2001-07 through 2001-09,
(see TODO)?  generally, what does it mean when someone claims a parent
task of an already claimed subtask?  what kind of dependency does this
set up?  what is the proposed conflict resolution protocol?

(we can ignore these hairy questions by claiming only leaf tasks, or we
can take some time to think about the questions and record the answers
somewhere (eg, README), or we can look forward to unpleasant confusion.)

thi

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

Re: More Bug Stuff

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <ttn@giblet.glug.org>
   Date: Sun, 07 Apr 2002 12:05:59 -0700

   what does it mean when someone claims a parent task of an already
   claimed subtask?  what kind of dependency does this set up?  what is
   the proposed conflict resolution protocol?

i've added these questions to tasks/README.

thi

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

Re: More Bug Stuff

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 07 Apr 2002 13:17:49 +0200
> 
>    I have ticked all bug reports in my local archives anyway, so I'll
>    just import those.  I think this will be reasonably complete.
> 
> would you like me to not look at m.l. archives 2001-07 through 2001-09,
> (see TODO)?

Yes, please do.

> generally, what does it mean when someone claims a parent task of an
> already claimed subtask?  what kind of dependency does this set up?
> what is the proposed conflict resolution protocol?

Yeah, difficult.  I claimed the whole baby but then it occurred to me
that it is not a really meaningful thing to do.  I will take that back
and just add the proper subtask with the proper timeframe.

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

Re: More Bug Stuff

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 07 Apr 2002 14:03:41 +0200

   The numbers themselves don't mean anything, so when you need to chose
   a priority for a bug you'll pick a number that you feel expresses your
   idea of the bugs priority.  Other people will chose different numbers
   although they might want to express the same idea of priority.

(also same numbers may express different ideas, since the task of fixing
any particular bug really part of the big Life TODO list. :-)

thi

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