Re: More Bug Stuff

[Evan Prodromou <evan@glug.org>]

>>>>> "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