Re: More Bug Stuff

[Marius Vollmer]

Evan Prodromou <address@hidden> writes:

> >>>>> "MV" == Marius Vollmer <address@hidden> 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.
]