unnecessary QA work (was Re: dapper-live test)

[Matthew Paul Thomas]

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

On May 8, 2006, at 11:49 AM, Colin Watson wrote:
> ...
> In case (a)'s failure mode (a duplicate bug), every bug tracking  
> system I've ever worked with, including Malone, can deal with the  
> situation easily. You mark the bug as a duplicate, perhaps adding a  
> comment, and move on.

Eventually you may even be able to do these things in a single page  
load. :-)

> In case (b)'s failure mode (comment about a bug attached to a  
> different existing bug), I've never seen a bug tracking system that  
> deals with the situation gracefully. The best I've seen is the 'clone'  
> command in debbugs, which at least allows you to split off the bug  
> history to another bug and then deal with the two parts independently,  
> but even that isn't particularly great. I've never seen a system that  
> allows a developer to hide extraneous comments to avoid them causing  
> confusion to that developer in the future when they come to work on  
> the bug, so the failure mode always leaves permanent noise

I designed a solution for this last year, though it hadn't occurred to  
me that it would be used for reducing confusion between related bugs. I  
thought it would be used just to cut down on chatter. Feedback  
appreciated. <https://wiki.launchpad.canonical.com/KeepingBugsConcise>

> ...
> Malone's searching interface is not all it could be. For instance:
>
>   https://launchpad.net/products/malone/+bug/33881
>   https://launchpad.net/products/malone/+bug/33881
>
> ... and compare the experience of the reporter of
> https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/43230.

This is a combination of navigation problems, but mainly lack of smart  
search that detects product/package names in your search string.
<https://wiki.launchpad.canonical.com/MaloneSearch#head 
- -395e974fbaac48ee722e01e45987d2d5e0bebea1>

> Furthermore, it's not always at all obvious where to look for a bug.
> Perhaps in the case of simple self-contained applications it's not too
> difficult, but complicated subsystems like the installer or hardware
> detection or font management have their bugs spread out over a number  
> of packages and it's not even conceptually easy for Malone to guide  
> users to the right place; it's increasingly infeasible to search  
> through all Ubuntu bugs for an issue unless you happen to be  
> technically savvy enough to know the right technical terms to search  
> for

This would partly be addressed by smart cross-references
<https://launchpad.net/products/malone/+bug/37425>.

> (as far as I can tell, Malone full-text searches only search the  
> description and similar fields, not all comments).
> ...

That's by design. You can update a bug's description to include all  
relevant text (though this should be easier to do). And if comments  
were included in the search, not only would it be much slower, but your  
(b) above would also be more of a problem, because bug reports would be  
more often turning up in searches for unrelated bugs.

- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFEXwFR6PUxNfU6ecoRAtL3AJ9PwFoN1kxidyv8s67pKP2rUeqNhgCgslm/
NUAFx3zYqJr+BOcMJVzDbvg=
=qsGA
-----END PGP SIGNATURE-----