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