launchpad-dev team mailing list archive

[Michael Hudson <michael.hudson@xxxxxxxxxxxxx>]

Matthew Paul Thomas wrote:
> 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.

To cope with that, perhaps, the dupe finder should present bugs that
were marked as duplicates of the gtk+ bug (and the gtk+ bug as well, of
course).

"Your bug report 'Delete user confirmation dialog label has wrong size'
seems similar to 'Frobnozzle dialog label has wrong size' which was
marked as a duplicate of 'Height-for-width wrapping for GtkLabel'" or
something.

That, coupled with taking into account the dependencies of the package
being searched would be pretty awesome, even if it's rather science
fiction-ish today.

Cheers,
mwh