Link between project and package bug listings, or combine them

Bug #3152 reported by Matthew Paul Thomas on 2005-10-14
68
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself
High
Unassigned

Bug Description

Sebastien Bacher entered "gnome-utils" in the search form on <https://launchpad.net/>, and the only result was <https://launchpad.net/products/gnome-utils>. From there he clicked "Bugs", and was confused that bug 3118 didn't show up. The reason was that bug 3118 had been reported on the Ubuntu gnome-utils package, but not on the upstream project.

Similarly from irc.gnome.org/#epiphany (apparently after seeing https://launchpad.net/distros/ubuntu/breezy/+sources/epiphany-browser/+bugs):
<crispin> is it just me, or is launchpad damn confusing
<crispin> I have found another page about ephy which claims no bugs are reported against it
<crispin> https://launchpad.net/products/epiphany-browser

And an example of the opposite case, from bug 40622: "DUPLICATE. The frikkin https://launchpad.net/distros/ubuntu/+source/ubuntu-docs/+bugs doesn't show a single bug for me"

To fix these problems, Launchpad should provide prominent links from package bug listings to the equivalent project bug listings, and from project bug listings to the equivalent package bug listings (for those packages which have bugs not filed on the project).

For actually combining the listings, see bug 138545.

See also bug 76416.

Related branches

Christian Reis (kiko) wrote :

I would sustain that you /always/ want to show package bugs when querying for bugs on a product that the context packages. You could return, for instance, two sections:

Bugs on Firefox (upstream)

  Bug 1223: Need lunch

Bugs on Firefox in Distribution Packages

  Bug 1222: No lunchbox, no lunch

This would also solve the problem above (perhaps in a neater fashion)

description: updated
Matthew Paul Thomas (mpt) wrote :

Not for the upstream maintainers whose standard answer, to any question from someone on distro X wondering why the software isn't working properly, is "the X packagers are incompetent, install from source".

Brad Bollenbach (bradb) on 2005-11-23
Changed in malone:
assignee: nobody → bradb
status: New → Accepted
Christian Reis (kiko) wrote :

It wouldn't make it any worse to /display/ the bugs to people searching through upstream. In fact, it would make it better, because more people would notice that a bug was already open on their problem in a distribution package.

I see your point in that upstream has bugs in packages that will show up even if they don't want to fix them. But I propose dealing with that when and if somebody complains (I think most would appreciate it).

Le 28-Nov-05 à 1:52 PM, Christian Reis a écrit :

> Public bug report changed:
> https://launchpad.net/malone/bugs/3152
>
> Comment:
> It wouldn't make it any worse to /display/ the bugs to people
> searching
> through upstream. In fact, it would make it better, because more
> people
> would notice that a bug was already open on their problem in a
> distribution package.
>
> I see your point in that upstream has bugs in packages that will
> show up
> even if they don't want to fix them. But I propose dealing with that
> when and if somebody complains (I think most would appreciate it).

+1.

Cheers,

--
Brad Bollenbach

description: updated

I have come across this problem with
<https://launchpad.net/products/synaptic/+bugs>
and
<https://launchpad.net/distros/ubuntu/+source/synaptic/+bug/>

I think the most important issue is that users should be able to easily find the
distro package page with a search on the product name, and there should be
a link to an external bug page if available.

Toby

Sam Brightman (sambrightman) wrote :

I found this incredibly confusing at first and it still seems to be a problem. The solution proposed here seems about right to me - but if rationale is required I would say that someone coming to http://launchpad.net and searching for a product X would reasonably expect to see in the results all products named X being tracked by launchpad, upstream or otherwise. Whether or not the user has to choose a specific product before being shown the bugs and the possibility of links between them is neither here nor there in my view - the key is that they search for a product and are puzzled by only getting a very limited view. I'm not sure that I understand the objection regarding upstream developers - surely they can just ignore the results that aren't upstream?

Changed in malone:
assignee: bradb → mpt
importance: Medium → High
Changed in malone:
assignee: mpt → nobody
description: updated
James Westby (james-w) wrote :

This hit me as well. I would suggest having a

  N bugs in ...

somewhere on the main bug listing, and/or main bug page for each other location that
could be linked to the current, so the product would get

  N bugs in product (Ubuntu)

and Ubuntu would get

  N bugs in product.

With these links clickable obviously.

I maintain a native package, so the distinction seems pretty unnecessary to me, but
for normal packages I can see why.

Christian Reis (kiko) on 2007-10-29
Changed in malone:
milestone: none → 1.2.3
Changed in malone:
milestone: 1.2.3 → 1.2.5
Björn Tillenius (bjornt) wrote :

Untargeting this for now to help with planning. Will retarget it later.

Changed in malone:
milestone: 1.2.5 → none
description: updated
summary: - Prominently link between product bug listings <-> equivalent package bug
+ Prominently link between project bug listings <-> equivalent package bug
listings
Curtis Hovey (sinzui) on 2009-10-15
tags: removed: fix-it-friday
Deryck Hodge (deryck) on 2010-03-16
tags: added: prod-strategy
tags: added: bridging-the-gap
removed: prod-strategy
Bryce Harrington (bryce) on 2010-06-14
Changed in malone:
assignee: nobody → Bryce Harrington (bryceharrington)

Some rough mockups, so I can gather some feedback on what this really should look like.

This first mockup shows a 'Distro Packaging' portal that'd link to various distros that provide packaging. So this would link to e.g. "https://launchpad.net/fedora/+source/jokosher" for Fedora, and so forth.

Obviously, I just recycled the top bit of the Get Involved portlet, but do you think the placement here on the right underneath Downloads is the right location for it? Will it be sufficiently discoverable there? I debated about whether it should be lower down on the page so it doesn't displace Get Involved and Announcements; it's debatable whether it's going to be as important as those. Thoughts?

Bryce Harrington (bryce) wrote :

This one shows links from the project's bug page to the distro packages.

Formatting-wise I like this portlet style the best.

Bryce Harrington (bryce) wrote :

Finally, this shows the inverse... from a distro source package's bug page, link to the upstream package bugs.

I thought it'd be useful to show a breakdown of bugs ala the bugfilters here. I'm concerned people could get confused between the regular bugfilter list (second portlet from the top) and this one, especially if they're unfamiliar with the term 'Upstream', but maybe this is ok? What do you guys think.

On Wed, 16 Jun 2010 01:03:51 -0000, Bryce Harrington <email address hidden> wrote:
> Some rough mockups, so I can gather some feedback on what this really
> should look like.
>
> This first mockup shows a 'Distro Packaging' portal that'd link to
> various distros that provide packaging. So this would link to e.g.
> "https://launchpad.net/fedora/+source/jokosher" for Fedora, and so
> forth.
>
> Obviously, I just recycled the top bit of the Get Involved portlet, but
> do you think the placement here on the right underneath Downloads is the
> right location for it? Will it be sufficiently discoverable there? I
> debated about whether it should be lower down on the page so it doesn't
> displace Get Involved and Announcements; it's debatable whether it's
> going to be as important as those. Thoughts?

I don't think it's important enough to warrant being above Get Involved
and Downloads. I also don't think it's important enough to warrant being
the bold font that it is.

I was sure there used to be packaging links on a project page, but I
can't find them now. sinzui was recently working on improving it so
that it offered you packages to link.

I like the other two mockups though.

Thanks for working on this.

James

FWIW, I think that the new portlet should be below "Get Involved".

We haven't used the word "Distro" in official text before, and I'm not convinced we should start now. How about just heading the portlets "Packaging" and "Bugs in Packages"? The content of the portlet will make it clear which sort of packaging we mean.

Other than that, looks great. Thanks so much for getting to this.

Matthew Paul Thomas (mpt) wrote :

I'm delighted this is being worked on, but I'm bothered at how long it took me to find the new links in the mockups, even though I knew what I was looking for. I think "grey box on the right side of the page" is a Launchpad anti-pattern.

A non-grey-box presentation could be much simpler. One sentence, below the bug listing: "See also bugs reported about Jokosher in _Ubuntu (42)_, _Debian (42)_, and _Fedora (4234)_."

Similarly on the project overview page: "Jokosher is packaged in _Ubuntu_, _Debian_, _Slackware_, and _Fedora_. (_Others?_)"

On Fri, Jun 25, 2010 at 10:52:48AM -0000, Matthew Paul Thomas wrote:
> I'm delighted this is being worked on, but I'm bothered at how long it
> took me to find the new links in the mockups, even though I knew what I
> was looking for. I think "grey box on the right side of the page" is a
> Launchpad anti-pattern.

Well I can't say I'm a huge fan either, but Launchpad uses this design
pattern quite extensively for similar chunks of information throughout
the bug pages.

> A non-grey-box presentation could be much simpler. One sentence, below
> the bug listing: "See also bugs reported about Jokosher in _Ubuntu
> (42)_, _Debian (42)_, and _Fedora (4234)_."
>
> Similarly on the project overview page: "Jokosher is packaged in
> _Ubuntu_, _Debian_, _Slackware_, and _Fedora_. (_Others?_)"

One thing we ought to keep in mind esp. in considering other designs, is
there is potentially quite a number of distributions that could show up
in this list.

With where it is in the current mockup, I figure it could probably grow
to 15 items or so before it needs cut off. With it implemented as links
in a sentence, probably 4-5 items would be a limit. Distrowatch lists
11 distros on its main page (13 if you count RHEL and SLES as distinct
from Fedora and OpenSUSE).

The nice thing about the grey-box habit is that Launchpad doesn't need to quit all at once: individual elements can escape separately. ;-) Meanwhile, after about four years, only two distributions have more than 100 open bug reports in Launchpad: Ubuntu and Baltix. And I think only two have packaging records in Launchpad: Ubuntu and Debian. Those sentences won't soon get long.

Bryce Harrington (bryce) wrote :

Postponing this for now. Was hoping to get some clarification on what to do this week, but feedback so far is everyone seems to have different incompatible ideas.

Changed in malone:
assignee: Bryce Harrington (bryceharrington) → nobody
Curtis Hovey (sinzui) wrote :

The registry team will take up this issue.

Changed in malone:
milestone: none → 10.11
assignee: nobody → Curtis Hovey (sinzui)
Curtis Hovey (sinzui) wrote :

After talking with users who work with projects that work closely with Ubuntu, the users need a way to combine listings.
    As a contributor to upstream and downstream,
    I want an option to see combined bug listings,
    So that I can coordinate my work.

When a project does not use Lp, to track bugs, the bugs page includes links to the Ubuntu package bug listings. In the case where both the project and Ubuntu use Lp, providing a combined bug listing will allow the two communities collaborate in triage and planning. Show a link is fine, but that does not reduce the contributor's effort very much. The contributor really needs to dedupe bugs, get the importance right, and track the progress.

Changed in malone:
assignee: Curtis Hovey (sinzui) → Registry Team (launchpad-registry)
summary: - Prominently link between project bug listings <-> equivalent package bug
- listings
+ Link between project and package bug listings, or combine them
Curtis Hovey (sinzui) on 2010-11-12
Changed in malone:
milestone: 10.11 → 10.12
Curtis Hovey (sinzui) on 2010-11-15
Changed in malone:
assignee: Registry Team (launchpad-registry) → Curtis Hovey (sinzui)
status: Triaged → In Progress
tags: added: qa-needstesting
Changed in malone:
status: In Progress → Fix Committed
Curtis Hovey (sinzui) on 2010-11-24
tags: added: qa-ok
removed: qa-needstesting
Changed in malone:
status: Fix Committed → Fix Released
Jonathan Lange (jml) wrote :

Not released yet.

Changed in malone:
status: Fix Released → Fix Committed
Curtis Hovey (sinzui) on 2010-12-08
Changed in malone:
status: Fix Committed → Fix Released
description: updated
Curtis Hovey (sinzui) on 2017-05-15
Changed in launchpad:
assignee: Curtis Hovey (sinzui) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers