RFC: bug-handling doc tweaks

[Martin Pool]

2009/8/29 Eric Siegerman <lists08-bzr at davor.org>:
> 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.

Oops.

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

I don't have any new thoughts on this.  There's a grey area between "I
might work on this someday" and "I am working on it this very second",
so the question is where you draw the line.  To me assigned but not in
progress is a useful gradation of "I'm interested in doing this".

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



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

Yes.

>  - Is it really a no-op?  Clearly if LP sends you duplicate
>    emails this idea's a non-starter.

That does seem to work.

It has the slight drawback that
https://bugs.edge.launchpad.net/~mbp/+subscribedbugs has >600 bugs in
various projects, but we could use this going forward.  I could
bookmark another link of bzr bugs I'm personally subscribed to.  I
suppose I'm already using subscribed for a lower level of "interested
in", but that's only in non-bzr projects.  Possibly bugs I'm
individually subscribed to in bzr would count as "interested in".

>> > + 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.

I think that'd be good.

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

The problem with this is that in practice it creates mental load on
the RM to keep presenting them with bugs that they probably should not
take any action upon.

And the question is, how should those bugs be treated differently from
other bugs of equal priority?  Should a medium-2.1 bug be done before
or after a high-untargeted bug?

Perhaps people would be using this as a way to get finer gradations of
priority between bugs at the same level.

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

Sounds good.

-- 
Martin <http://launchpad.net/~mbp/>