RFC: bug-handling doc tweaks

Eric Siegerman lists08-bzr at davor.org
Sat Aug 29 04:11:09 BST 2009


An outsider's thoughts:

On Thu, 2009-08-27 at 14:02 +1000, Martin Pool wrote:
> To be honest I can see there is a problem here but I don't want to
> think about it this week.

Don't read any further till 2.0 final is out, then. :-)/3
Until then, whatever works for you wearing your RM hat, wins in
my book.

But longer term, though I don't have much of a stake in it, my
sympathy's with Rob on this.  Assigning a bug feels like it
should make a stronger statement than "I might want to look at
this some day".  Besides, a bug can only be assigned to one
person (or team, whatever), which prevents multiple people from
adding it to their "itch I want to scratch" lists.  And the more
people it's itching (and who've kept track of the fact), the
faster one of them will scratch it.

So on to some concrete suggestions.

> > Perhaps using a tag 'mbp-fave' or something would be good.
> 
> That could be good.  Tags are harder to use than assignment though,
> which is itself a bug.

How about subscribing to the bug.  For you bzr-core folks that's
a no-op as far as email is concerned, but it's a nice,
*nonexclusive* way of registering interest.  Issues:
  - Will Launchpad let you do that, if you're a member of a team
    that's already subscribed?
  - Is it really a no-op?  Clearly if LP sends you duplicate
    emails this idea's a non-starter.


> > So, you'd prefer:
> > + 1. Progressing bugs that are critical.
> > + 1. Progressing bugs targeted to a release.

If "critical" was *defined* as release-blocker bugs:
  - the friction between critical and release-blocker would
    vanish.  (Though this would be a no-op, the second item could
    for clarity be modified to "progressing noncritical bugs
    targeted to a release".)

  - it would no longer be bad to target non-blocker bugs to a
    release, as the the priority would make it easy for the RM to
    tell them apart

To make "critical implies release-blocker" reasonable, it would
make sense (to me anyway) to demote "represents a regression in
something previously working" from "critical" to "high".  Note
that this wouldn't prevent regressions from being classified as
critical on their (de)merits if appropriate, just not because of
their regression-ness per se.

  - Eric





More information about the bazaar mailing list