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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
