launchpad-dev team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

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

Robert Collins wrote on 03/11/09 20:46:
> 
> On Tue, 2009-11-03 at 12:42 +0000, Matthew Paul Thomas wrote:
>> 
>> Throughout our design process in 2005 and 2006, our routine examples
>> for project groups (then known as "projects") were Gnome, KDE, and
>> Mozilla. For groups like those, you would not want the dup finder to
>> work across the project group; for example, it would make no sense
>> for a bug search in the Totem project to turn up bugs reported on
>> Cheese, or for a bug search in the Fennec project to turn up bugs
>> reported on Thunderbird.
> 
> !citation

I gave a couple of examples. If you want more, go to
<https://bugzilla.gnome.org/query.cgi>,
<https://bugs.kde.org/query.cgi?format=advanced>, or
<https://bugzilla.mozilla.org/query.cgi>, and choose any pair of items
from the "Product" list. :-) For most (though not all) of those pairs,
suggestions from one would be irrelevant and possibly even frustrating
when reporting a bug on the other.

> A bug in glib will cause a segfault at approximately the same place
> much of Gnome. What is the basis for saying that the dup finder should
> /not/ work across all these products (or indeed wider afield).
> Assertion: Users filing bugs do not know which libraries are in use,
> but the fault is most likely in the transitive closure of the packages
> dependencies.

That's true. For some projects -- like glib, or GTK, or PolicyKit, or
Aptdaemon -- bugs in those components are likely to be misfiled against
applications that use the components.

> I'd say that the dup finder should work more broadly than project
> groups, when we have backtrace and installed dependency data; where we
> only have a text description, any data we do have about project
> relationships could help get a decent match (say from libxml2 rather
> than evolution, even though the user thinks its evolution).

That would be really cool. I'm skeptical, though, that the bug summaries
in those lower-level components would often be both close enough and
obvious enough to deter people from reporting application-oriented
duplicates.

For example, in GTK there is a bug where text labels often don't take up
the full width of the available space: this bug report has the summary
"Height-for-width wrapping for GtkLabel"
<https://bugzilla.gnome.org/show_bug.cgi?id=101968>. When someone sees
that bug manifest in an application, they report a duplicate bug about
that application with a summary like "Delete user confirmation dialog
label has wrong size"
<https://bugzilla.gnome.org/show_bug.cgi?id=585195>, or "line breaks are
harcoded" <https://bugzilla.gnome.org/show_bug.cgi?id=492988> -- neither
of which bear any resemblance to the summary of the original bug report.
Maybe the original could be resummarized to be more obvious, e.g.
"Multi-line text labels don't use available width (no height-for-width
wrapping)", but for bug supervisors to do this would be a non-obvious
investment on their part.

- --
Matthew Paul Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrxbJ4ACgkQ6PUxNfU6ecoalgCdE17oCBCdplRxAdj4N9y+L8Kq
nG8An3p258ILtPrcBnr0zcwgD0vFMPEr
=/Sci
-----END PGP SIGNATURE-----