Bug listings for projects that don't use Launchpad Bugs need clarification

[Emmanuel Rodriguez]

When a project does not use Launchpad for bug tracking, its Bugs page does not say so, though it may nevertheless list some bugs (those with bug watches set up, and those caused by bug 33642 and bug 34343). This is confusing.

One solution would be to begin the project's Bugs page with an explanation that the project does not use Launchpad for bugtracking, including a link to the project's real bug tracker if we know it.

The fix for this bug can probably share some of the code used to fix bug 42480. It may also make sense to fix bug 3152 at the same time as this bug.

[Dafydd Harries (daf)]

What behaviour were you expecting? I see two possiblities:

 * you expect to be able to file a bug on Linux in Malone even though it's likely that Linux developers will never see it
 * you are using Ubuntu and are experiencing a Linux bug

I suspect the latter. Perhaps this page should suggest that you should file a bug for the distribution you're using.

[Dafydd Harries (daf)]

Sorry, I misunderstood. Indeed, it's confusing that we show existing bugs when you can't file new ones. Short of hiding or deleting bugs for products that don't use Malone, or moving the bugs to Ubuntu, I'm not sure what we can do about it.

[Björn Tillenius (bjornt)]

On Mon, Mar 20, 2006 at 10:29:46AM -0000, Dafydd Harries wrote:
> Sorry, I misunderstood. Indeed, it's confusing that we show existing
> bugs when you can't file new ones. Short of hiding or deleting bugs for
> products that don't use Malone, or moving the bugs to Ubuntu, I'm not
> sure what we can do about it.

Yeah, it's a hard problem to solve. Maybe we shouldn't show bug
listings of products that don't use Malone. These bugs haven't been
added been added by filing them directly on the product, they were
first filed in Ubuntu, and then "forwarded" to the product, which is a
perfectly valid thing to do.

I think we need to try to explain this in the UI somehow. Hiding the
bugs isn't a correct thing to do, since it can be good to get a overview
of all the bugs in product, even if it doesn't use Malone directly. Soon
we'll start syncing the status of the bugs from the upstream bugtracker.

[Brad Bollenbach (bradb)]

On 3/20/06, Björn Tillenius <email address hidden> wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/35646
>
> Comment:
> On Mon, Mar 20, 2006 at 10:29:46AM -0000, Dafydd Harries wrote:
> > Sorry, I misunderstood. Indeed, it's confusing that we show existing
> > bugs when you can't file new ones. Short of hiding or deleting bugs for
> > products that don't use Malone, or moving the bugs to Ubuntu, I'm not
> > sure what we can do about it.
>
> Yeah, it's a hard problem to solve. Maybe we shouldn't show bug
> listings of products that don't use Malone. These bugs haven't been
> added been added by filing them directly on the product, they were
> first filed in Ubuntu, and then "forwarded" to the product, which is a
> perfectly valid thing to do.
>
> I think we need to try to explain this in the UI somehow. Hiding the
> bugs isn't a correct thing to do, since it can be good to get a overview
> of all the bugs in product, even if it doesn't use Malone directly. Soon
> we'll start syncing the status of the bugs from the upstream bugtracker.

I agree that a message on the bug listing pages (and bug pages in that
context, perhaps) that explains how these bugs ended up in Malone when
the upstream isn't using Malone is probably a good starting point for
fixing this problem.

Cheers,

--
Brad Bollenbach

[Björn Tillenius (bjornt)]

On Mon, Mar 20, 2006 at 11:36:43AM -0000, Matthew Paul Thomas wrote:
> *** This bug has been marked a duplicate of bug 33642 ***

This bug is not the same as bug 33642. Bug 33642 talks about bugs that
were directly filed on the product before we added the restriction.
This bugs talks about the following scenario:

    1. A bug is filed on a package in Ubuntu

    2. A bug task is added on a product Foo

    3. The bug listings for Foo shows that there are bugs filed on Foo,
       but you can't actually filed new bugs directly on Foo, which is
       confusing.

[Emmanuel Rodriguez (potyl)]

I'm a little bit confused with Malone. I though that Malone was the place where to fill Ubuntu related bugs since Ubuntu doesn' use Bugzilla anymore.

In the meanwhile what should I do if I want to file a bug about the Ubuntu kernel regarding the module named 'rt2500'?

Should I go upstream?

[Brad Bollenbach (bradb)]

On 3/22/06, Emmanuel Rodriguez <email address hidden> wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/35646
>
> Comment:
> I'm a little bit confused with Malone. I though that Malone was the
> place where to fill Ubuntu related bugs since Ubuntu doesn' use Bugzilla
> anymore.
>
> In the meanwhile what should I do if I want to file a bug about the
> Ubuntu kernel regarding the module named 'rt2500'?
>
> Should I go upstream?

This is a question best answered by the Ubuntu developers, but if it
were me, I might start by reporting it on linux-source-2.6.15 (or do a
search for "rt2500" on existing Ubuntu bugs and see if that helps give
you an idea of where to file the bug.)

Cheers,

--
Brad Bollenbach

[Matthew Paul Thomas (mpt)]

In other words, if you find a bug in Ubuntu's kernel you should report it in Malone against the relevant Ubuntu kernel package, just like when Ubuntu used Bugzilla.

Meanwhile, besides bug 33642 and bug 34343, the only bugs showing up on these lists should be bug watches. So we need a little blurb on these pages saying something like: "X does not use Malone -- these reports mirror bugs in X's own bug tracker. Use that bug tracker to report bugs."

[Evan Carroll (evancarroll)]

I still find this slightly confusing:

Take this page for example: https://bugs.launchpad.net/chromium-browser/+bug/621786

I wanted to know where are the other bugs for Chromium-Browser. Clicking "bugs" in the menu-major at the top takes me here,

https://bugs.launchpad.net/chromium-browser

"Chromium Browser must be configured in order for Launchpad to forward bugs to the project's developers." doesn't seem to apply to me though. I'm just looking for other peoples bugs, like #621786. And, even if I wanted to file bugs, why do I really care if it is set to work with Chromium-browser upstream. We all know 95% of the bugs on launchpad are for Google, and single-login. Not to actually get stuff done. That's why the peon-team files and tracks them upstream after verifying them.

If that isn't clear, deleting the bug id in the URL isn't any better...

https://bugs.launchpad.net/chromium-browser/+bugs

Now I get a simple, "Chromium Browser does not use Launchpad for bug tracking." That still begs the question why was the original bug on Launchpad to begin with...

Alas, I'll check the overview

https://launchpad.net/chromium-browser

But, still not a single mention of how bug tracking works; or, how the original bug was filed... This behavior is not typical of Launchpad. Because it stands out an infobox should inform the user what is going on each Launchpad page in the project. Especially, the user's original landing page...

https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/621786

[Gavin Panella (allenap)]

> I still find this slightly confusing:
...

Discussion continues in bug 787654.