That need to close bugs?
surak at ubuntu.com
Wed Sep 12 07:19:17 UTC 2007
2007/9/12, Matthew Paul Thomas <mpt at canonical.com>:
A bug report takes up exactly the same amount of disk space regardless
> of whether it is open or closed.
> What's most important is making the best use of developer time. That in
> turn requires making the best use of QA time, because an efficient QA
> team will be more likely to convey accurately which bugs developers
> should be working on.
> So the QA team need to balance the probability that aggressively
> declining incomplete bug reports will lead to more duplicates being
> reported, against the probability that leaving bug reports open will
> make searching harder and slow down QA in general.
there are important bugs not being fixed from version to version, but
instead being closed.
A new release that doesn't fix a bug must not close the bug just because it
was posted a long time ago or because the OP is not a debugging expert. This
generates two things:
- Other people will report it again. Newer reports are not necessairily
better than a "mee too" with more detail on a bug.
- Frustration, as the poster will not find the same error with other people,
and waste time looking if the problem is his.
I've passed through both situations recently. One for a prism54 hardware,
where the bug was recently closed on hardware. The kernel reported that my
hardware is faulty as soon as I upgraded from feisty to gutsy. Damn, how can
it be faulty? I just used it to download the 700mb+ of the upgrade!
Then, I searched for the bug on launchpad and nothing. Lacking a cd to
reinstall Ubuntu (and no network on ubuntu anymore), I installed a windows
just to be able to test the prism54 card again.
The card worked perfectly. I then went to launchpad again (about three hours
later) to submit the bug. When I submitted, I found a similar one, closed.
This is what I call frustration...
surak at ubuntu.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ubuntu-devel-discuss