RFC: bug-handling doc tweaks

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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

I've used it when I'm actually working on a bug and expect to have a fix
for 2.1. So possibly a bigger push for people to review the medium-2.1
bug that I did in the 'slack space' of development time.

I don't think non-blocking bugs that aren't being worked on should be
targetted.

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

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqpAgUACgkQJdeBCYSNAAP9nwCgmhyQ60mg18YO7boRhtk0bVBW
31kAnRj/geD/ZhuEnJ8jm6ArojW8K0GW
=DnmD
-----END PGP SIGNATURE-----