No bugs found when looking at a distro-series specific bug page, but many open on the distro scoped bug page

Example of such bugs are bug #36643, bug #36474.

Sylvain, tell me more about step 3. Between entering the package name and clicking on "Bugs", do you:
3.1. Click "Search" to arrive at a page like <https://launchpad.net/distros/ubuntu/+search?text=gconf-editor>?
3.2. Click on one of the results, to arrive at a page like <https://launchpad.net/distros/ubuntu/+source/gconf-editor>?

I think the real issue here bug 3620. If Malone had a yellow brick road filebug workflow that included a duplicates search, there would be no question in the user's mind about how to find dupes.

If, indeed, you're seeing bugs in the "latest bugs" portlet and they weren't showing up in the +bugs listing for that package, that's a (different) bug.

I'm doing step 3.1 then 3.2. In fact, I'm visiting the following pages in order (new step number) :
 1. https://launchpad.net/
 2. https://launchpad.net/distros
 3. https://launchpad.net/distros/ubuntu
 4. https://launchpad.net/distros/ubuntu/+search?text=gconf-editor
 5. https://launchpad.net/distros/ubuntu/+source/gconf-editor
 6. https://launchpad.net/distros/ubuntu/dapper/+source/gconf-editor
 7. https://launchpad.net/distros/ubuntu/dapper/+source/gconf-editor/+bugs

As the list presented in step 7 is empty, I click on report a bug, and thus visit the following pages, in order:
 8. https://launchpad.net/distros/ubuntu/+source/gconf-editor/+filebug
 9. https://launchpad.net/distros/ubuntu/+source/gconf-editor/+bug/36643

(There may exist some pages between step 8 and 9, I do want to post a new bug to see if there are or not).

An there, I see that there are other bugs on the gconf-editor packages, in the ubuntu distrribution that weren't present in the list found in step 7. One of which my recently reported bug is a duplicate.

Sylvain, thanks for that excellent breakdown. As far as I can tell, you didn't see those bugs for two reasons.

1: The bugs were filed against a distribution source package (gconf-editor in Ubuntu), and you were looking at the Bugs page for a distribution *release* source package (gconf-editor in Ubuntu Dapper). Malone treats these as if they're completely separate entities.

2: The bugs are fixed. If all open bugs in something are fixed, a Bugs page makes it look for all the world as if it's never had bugs in it at all. It should at least include a list of recently-fixed bugs. (Possibly the developers are also using Fix Released when they should use Fix Committed, I don't know.)

These are separate problems. How about we use this bug report to track fixing the first problem?

On Mon, 2006-04-03 at 09:34 +0000, Matthew Paul Thomas wrote:
> Sylvain, thanks for that excellent breakdown. As far as I can tell, you didn't see those bugs for two reasons.
>
> 1: The bugs were filed against a distribution source package (gconf-editor in Ubuntu), and you were looking at the Bugs page for a distribution *release* source package (gconf-editor in Ubuntu Dapper). Malone treats these as if they're completely separate entities.

Should we even *have* a +bugs list for a distrorelease? I'd wager that
only the most determined user will be able to clearly explain the
difference between:

  /distros/ubuntu/+bugs

and:

  /distros/ubuntu/dapper/+bugs

and only because somebody already explained it to them (who, themselves,
probably got the answer from me...okay, I think I made my point.)

An alternative way to present a list of bugs targeted for a release,
that doesn't have you falling down the laundry shoot and coming out in
distrorelease land (which is a vague distinction to most, I think),
would be to treat release target as another search criterion. The
sidebar that has links to release-targeted bugs would simply link to the
appropriate search filter
(e.g. /distros/ubuntu/+bugs?search=Search&release=dapper)

Thoughts?

Brad, we discussed distro release bugs pages at UBZ. People are going to be able to nominate bugs to be fixed in a particular release, and the distro release bugs page will list those bugs. However, regardless of whether the nomination scheme has been implemented, there should still be a prominent link from the distro release bugs page to the distribution bugs page.

On Fri, 2006-04-21 at 01:27 +0000, Matthew Paul Thomas wrote:
> Brad, we discussed distro release bugs pages at UBZ. People are going to
> be able to nominate bugs to be fixed in a particular release, and the

This much is obvious, and I'm not suggesting any change to this
workflow.

> distro release bugs page will list those bugs. However, regardless of

...but I am suggesting that having to go to a different part of
Launchpad (leaving the distribution context to go to the distrorelease
context) to see all bugs assigned to Dapper leads users (both newer, and
more experienced) to the following questions when they try to reconcile
the difference between 1. /distros/ubuntu/+bugs and
2. /distros/ubuntu/dapper/+bugs:

 * What's the difference between #1 and #2?

 * Why are there only 50 bugs open on dapper, but 10,000 open on Ubuntu?
(https://launchpad.net/distros/ubuntu/dapper/+bugs is 100% strange.)

 * Why can't I file a bug on dapper? (e.g. expecting that if +bugs
works, +filebug should work in both places, and being annoyed when they
get kicked back to the distro filebug page in this case.)

etc. Examples:

https://launchpad.net/products/malone/+bug/28710
https://launchpad.net/products/malone/+bug/32795

Can you think of good reasons for why bugs targeted to specific releases
can't be listed through using a simple search criterion added to
+bugs-advanced-search?

One argument could be that we might also develop special release
management reports and, I agree, that would be nice, but I still don't
see why that would mean having to force the user out of the distro
context and into the distrorelease one.

I think the solution I described solves the first two problems you listed. And the rest of the problems you listed affect neither this bug nor the proposed solution, so I'd suggest reporting them separately.

See also bug 100083 for a related issue