Gervase Markham wrote:
><sigh> No. Sorry to sound like a broken record, but this exercise is about
>deciding the release criteria - classes of bugs we think should be fixed.
>We specifically asked people not to name individual bugs, and they've been
>very good about that (mostly ;-).
>
I still don't understand you. I didn't ask for specific bugs to be fixed
- I did describe a class of bugs - "wrong/weird behaviour" - which
annoys me and which you didn't cover at all in your inital proposal.
That is, bugs which cause Mozilla to just misbehave. Not compatibility,
not crash. E.g. behaviour against reasonable and common expectation.
I will name a few *examples*, to make clear which bugs I mean, because
obviously, am misunderstood here:
* The cursor in the editor, both HTML (Mailnews) and plaintext (HTML
forms) sometimes is at the wrong position, making it sometimes
extremely hard and annoying to use HTML forms.
* If I collapse a tree node under Linux, the whole tree stops to redraw.
None of these bugs appear in any of your "classes" of bugs, so by your
criteria would not be 1.0 blockers. I think, they are, with several
other bugs of the same kind. So, this is very much "what this exercise
is about". (The topic was to find criterias for 1.0, not?)
>>>We probably don't have
>>>enough QA people to comb through them in an ordered fashion, checking each
>>>one.
>>>
>>Why am I filing them, then?
>>
>Good question. You might like to find or hire some more QA volunteers ;-)
>
Honestly, I do think that Mozilla has enough QA resources to sort the
open bugs into classes of importance. By far, actually.
I think, the problem is to agree on an importance of individual bugs.
(Importance = Is that particular bug a 1.0 blocker? Or just a "should
fix for 1.0"? Or not important for 1.0?)
