Link between project and package bug listings, or combine them

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)

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".

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

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

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?

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.

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

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?

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

Formatting-wise I like this portlet style the best.

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.

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.

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.

The registry team will take up this issue.

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.

Fixed in stable r11965 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/11965>.

Not released yet.