* More Bug Stuff
@ 2002-03-24 20:23 Evan Prodromou
2002-03-24 23:03 ` Marius Vollmer
0 siblings, 1 reply; 22+ messages in thread
From: Evan Prodromou @ 2002-03-24 20:23 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: More Bug Stuff
2002-03-24 20:23 More Bug Stuff Evan Prodromou
@ 2002-03-24 23:03 ` Marius Vollmer
2002-03-25 8:21 ` Thien-Thi Nguyen
2002-03-28 16:52 ` Evan Prodromou
0 siblings, 2 replies; 22+ messages in thread
From: Marius Vollmer @ 2002-03-24 23:03 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: More Bug Stuff
2002-03-24 23:03 ` Marius Vollmer
@ 2002-03-25 8:21 ` Thien-Thi Nguyen
2002-03-25 15:48 ` Rob Browning
2002-03-25 21:35 ` Marius Vollmer
2002-03-28 16:52 ` Evan Prodromou
1 sibling, 2 replies; 22+ messages in thread
From: Thien-Thi Nguyen @ 2002-03-25 8:21 UTC (permalink / raw)
Cc: evan, guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: More Bug Stuff
2002-03-25 8:21 ` Thien-Thi Nguyen
@ 2002-03-25 15:48 ` Rob Browning
2002-03-25 21:19 ` Thien-Thi Nguyen
2002-03-25 21:35 ` Marius Vollmer
1 sibling, 1 reply; 22+ messages in thread
From: Rob Browning @ 2002-03-25 15:48 UTC (permalink / raw)
Cc: mvo, evan, guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: More Bug Stuff
2002-03-25 8:21 ` Thien-Thi Nguyen
2002-03-25 15:48 ` Rob Browning
@ 2002-03-25 21:35 ` Marius Vollmer
2002-03-25 22:00 ` Thien-Thi Nguyen
` (2 more replies)
1 sibling, 3 replies; 22+ messages in thread
From: Marius Vollmer @ 2002-03-25 21:35 UTC (permalink / raw)
Cc: evan, guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: More Bug Stuff
2002-03-25 21:35 ` Marius Vollmer
@ 2002-03-25 22:00 ` Thien-Thi Nguyen
2002-03-25 22:03 ` Thien-Thi Nguyen
2002-03-27 0:31 ` Evan Prodromou
2 siblings, 0 replies; 22+ messages in thread
From: Thien-Thi Nguyen @ 2002-03-25 22:00 UTC (permalink / raw)
Cc: evan, guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: More Bug Stuff
2002-03-25 21:35 ` Marius Vollmer
2002-03-25 22:00 ` Thien-Thi Nguyen
@ 2002-03-25 22:03 ` Thien-Thi Nguyen
2002-03-25 22:25 ` Marius Vollmer
2002-03-27 0:31 ` Evan Prodromou
2 siblings, 1 reply; 22+ messages in thread
From: Thien-Thi Nguyen @ 2002-03-25 22:03 UTC (permalink / raw)
Cc: evan, guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: More Bug Stuff
2002-03-25 21:35 ` Marius Vollmer
2002-03-25 22:00 ` Thien-Thi Nguyen
2002-03-25 22:03 ` Thien-Thi Nguyen
@ 2002-03-27 0:31 ` Evan Prodromou
2002-03-27 2:58 ` Thien-Thi Nguyen
2002-03-27 18:56 ` Marius Vollmer
2 siblings, 2 replies; 22+ messages in thread
From: Evan Prodromou @ 2002-03-27 0:31 UTC (permalink / raw)
Cc: guile-devel
>>>>> "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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: More Bug Stuff
2002-03-27 0:31 ` Evan Prodromou
@ 2002-03-27 2:58 ` Thien-Thi Nguyen
2002-03-27 19:09 ` Marius Vollmer
2002-03-27 18:56 ` Marius Vollmer
1 sibling, 1 reply; 22+ messages in thread
From: Thien-Thi Nguyen @ 2002-03-27 2:58 UTC (permalink / raw)
Cc: mvo, guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: More Bug Stuff
2002-03-27 2:58 ` Thien-Thi Nguyen
@ 2002-03-27 19:09 ` Marius Vollmer
2002-03-27 20:39 ` Thien-Thi Nguyen
0 siblings, 1 reply; 22+ messages in thread
From: Marius Vollmer @ 2002-03-27 19:09 UTC (permalink / raw)
Cc: evan, guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: More Bug Stuff
2002-03-27 19:09 ` Marius Vollmer
@ 2002-03-27 20:39 ` Thien-Thi Nguyen
2002-04-07 11:17 ` Marius Vollmer
0 siblings, 1 reply; 22+ messages in thread
From: Thien-Thi Nguyen @ 2002-03-27 20:39 UTC (permalink / raw)
Cc: evan, guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: More Bug Stuff
2002-03-27 20:39 ` Thien-Thi Nguyen
@ 2002-04-07 11:17 ` Marius Vollmer
2002-04-07 19:05 ` Thien-Thi Nguyen
0 siblings, 1 reply; 22+ messages in thread
From: Marius Vollmer @ 2002-04-07 11:17 UTC (permalink / raw)
Cc: evan, guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: More Bug Stuff
2002-04-07 11:17 ` Marius Vollmer
@ 2002-04-07 19:05 ` Thien-Thi Nguyen
2002-04-07 21:22 ` Thien-Thi Nguyen
2002-04-07 21:38 ` Marius Vollmer
0 siblings, 2 replies; 22+ messages in thread
From: Thien-Thi Nguyen @ 2002-04-07 19:05 UTC (permalink / raw)
Cc: evan, guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: More Bug Stuff
2002-04-07 19:05 ` Thien-Thi Nguyen
@ 2002-04-07 21:22 ` Thien-Thi Nguyen
2002-04-07 21:38 ` Marius Vollmer
1 sibling, 0 replies; 22+ messages in thread
From: Thien-Thi Nguyen @ 2002-04-07 21:22 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: More Bug Stuff
2002-04-07 19:05 ` Thien-Thi Nguyen
2002-04-07 21:22 ` Thien-Thi Nguyen
@ 2002-04-07 21:38 ` Marius Vollmer
1 sibling, 0 replies; 22+ messages in thread
From: Marius Vollmer @ 2002-04-07 21:38 UTC (permalink / raw)
Cc: evan, guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: More Bug Stuff
2002-03-27 0:31 ` Evan Prodromou
2002-03-27 2:58 ` Thien-Thi Nguyen
@ 2002-03-27 18:56 ` Marius Vollmer
1 sibling, 0 replies; 22+ messages in thread
From: Marius Vollmer @ 2002-03-27 18:56 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: More Bug Stuff
2002-03-24 23:03 ` Marius Vollmer
2002-03-25 8:21 ` Thien-Thi Nguyen
@ 2002-03-28 16:52 ` Evan Prodromou
2002-03-29 4:02 ` Thien-Thi Nguyen
2002-04-07 12:03 ` Marius Vollmer
1 sibling, 2 replies; 22+ messages in thread
From: Evan Prodromou @ 2002-03-28 16:52 UTC (permalink / raw)
Cc: guile-devel
>>>>> "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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: More Bug Stuff
2002-03-28 16:52 ` Evan Prodromou
@ 2002-03-29 4:02 ` Thien-Thi Nguyen
2002-04-07 12:03 ` Marius Vollmer
1 sibling, 0 replies; 22+ messages in thread
From: Thien-Thi Nguyen @ 2002-03-29 4:02 UTC (permalink / raw)
Cc: mvo, guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: More Bug Stuff
2002-03-28 16:52 ` Evan Prodromou
2002-03-29 4:02 ` Thien-Thi Nguyen
@ 2002-04-07 12:03 ` Marius Vollmer
2002-04-07 22:22 ` Thien-Thi Nguyen
1 sibling, 1 reply; 22+ messages in thread
From: Marius Vollmer @ 2002-04-07 12:03 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: More Bug Stuff
2002-04-07 12:03 ` Marius Vollmer
@ 2002-04-07 22:22 ` Thien-Thi Nguyen
0 siblings, 0 replies; 22+ messages in thread
From: Thien-Thi Nguyen @ 2002-04-07 22:22 UTC (permalink / raw)
Cc: evan, guile-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2002-04-07 22:22 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-03-24 20:23 More Bug Stuff Evan Prodromou
2002-03-24 23:03 ` Marius Vollmer
2002-03-25 8:21 ` Thien-Thi Nguyen
2002-03-25 15:48 ` Rob Browning
2002-03-25 21:19 ` Thien-Thi Nguyen
2002-03-25 21:35 ` Marius Vollmer
2002-03-25 22:00 ` Thien-Thi Nguyen
2002-03-25 22:03 ` Thien-Thi Nguyen
2002-03-25 22:25 ` Marius Vollmer
2002-03-27 0:31 ` Evan Prodromou
2002-03-27 2:58 ` Thien-Thi Nguyen
2002-03-27 19:09 ` Marius Vollmer
2002-03-27 20:39 ` Thien-Thi Nguyen
2002-04-07 11:17 ` Marius Vollmer
2002-04-07 19:05 ` Thien-Thi Nguyen
2002-04-07 21:22 ` Thien-Thi Nguyen
2002-04-07 21:38 ` Marius Vollmer
2002-03-27 18:56 ` Marius Vollmer
2002-03-28 16:52 ` Evan Prodromou
2002-03-29 4:02 ` Thien-Thi Nguyen
2002-04-07 12:03 ` Marius Vollmer
2002-04-07 22:22 ` Thien-Thi Nguyen
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).