Separate "also affects: " Project and Distribution links are hard to use and confusing

"Request" seems like the wrong term to me. It seems like "Report this bug as being present in another Distribution/Upstream" would be more consistent. It's really reporting a bug (in the same sense as we use in our "Report a Bug" links) a second time, not making a support request or voting or explicitly bringing the bug to someone's attention.

So I think "Report this bug in another: + Distribution... + Upstream..." would be a better replacement.

I don't like the "Report this bug as being present..." wording because that's not what that function is for. For example, many of the bugs in Ubuntu 6.04 also occur in Ubuntu 4.10. But we don't want people to go around opening Ubuntu 4.10 tasks for all those bugs, because fixing bugs in 4.10 is no longer a priority, and developers would have to spend time marking them all Rejected. We'd want such tasks to be opened only for bugs that are either very serious, or experienced by paying customers who want the bug to be fixed. Hence, "Request fix". I'm not overly attached to that wording, though, so I'd be happy to read other suggestions.

What is the function for? It's not really clear to me.

I'm not sure that preventing unwanted bug reports for obsolete versions is any different here (adding a bug task) than reporting a new bug. Unhappy users will report bugs, and they'll need to be triaged. At least if the bugtask is explicitly rejected a future bug reporter searching for their bug will be able to see in a single page that their bug exists in 4.10 but is fixed in 6.04, and so can consider upgrading. Maybe it'll even show that it's fixed in 4.10 backports...

But I'm not overly attached to the "Report this bug as present in..." or "Request fix". I'm happy for other suggestions, but I've got no other ideas.

On Wed, Feb 01, 2006 at 03:31:39AM -0000, Andrew Bennetts wrote:
> But I'm not overly attached to the "Report this bug as present in..." or
> "Request fix". I'm happy for other suggestions, but I've got no other
> ideas.

I like "Report this bug as present in..." better than "Request fix",
since it handles the case where you already have a bug in a remote bug
tracker, and want to link the Malone bug to it. "Request fix" sounds
really awkward to me. There should be some better wording, but I can't
think of any.

"At least if the bugtask is explicitly rejected a future bug reporter searching for their bug will be able to see in a single page that their bug exists in 4.10 but is fixed in 6.04, and so can consider upgrading."

If someone using 4.10 is searching for a bug, they already know that it occurs in 4.10, so a 4.10 task isn't really necessary (except inasmuch as it reassures people that they have the right bug report). What I'm trying to avoid is people thinking they're being helpful by saying "hi, this also occurs in 4.10" (creating extra work in rejecting that task), when they don't actually want the bug fixed in 4.10, being quite happy to upgrade to 6.04 to get the fix instead.

(Perhaps the distinction between "occurs here" and "fix wanted here" was part of what "infestations" were meant to express?)

I agree the wording doesn't work well for opening a task just to link to an external bugtracker -- because it's the person who reported the bug in the external tracker, not you, who effectively requested the fix.

On 1-Feb-06, at 6:36 AM, Matthew Paul Thomas wrote:

> Public bug report changed:
> https://launchpad.net/malone/bugs/1334
>
> Comment:
> "At least if the bugtask is explicitly rejected a future bug reporter
> searching for their bug will be able to see in a single page that
> their
> bug exists in 4.10 but is fixed in 6.04, and so can consider
> upgrading."
>
> If someone using 4.10 is searching for a bug, they already know
> that it
> occurs in 4.10, so a 4.10 task isn't really necessary (except inasmuch
> as it reassures people that they have the right bug report). What I'm
> trying to avoid is people thinking they're being helpful by saying
> "hi,
> this also occurs in 4.10" (creating extra work in rejecting that
> task),
> when they don't actually want the bug fixed in 4.10, being quite happy
> to upgrade to 6.04 to get the fix instead.

FWIW, users should never be "requesting a fix"/reporting a bug/etc.
in a specific release. In the Malone model, release-specific always
means "backport/security fix", and we now have a backport-specific
UI. IMHO, the best UI for this is something like:

   <http://flickr.com/photos/84096161@N00/88275619/>

I think the layout of that page can be improved somewhat ($columns--,
among other things; I'm not really interested in a deep discussion of
the various aspects of this page outside what relates specifically to
this bug report), but I think the way it presents upstream status,
and reporting the bug elsewhere is pretty interesting.

What do you guys think?

Cheers,

--
Brad Bollenbach

For the record, this bug will be affected by the upstream bug workflow specification and work Bjorn, Brad and I discussed in London this past June.

Just curious as to the status on this bug? Isee the last update was 2006-08-08? Has it been fixed since? A little lost on trying to remember what the bug was reported for.

JOnathan

The next step is for me to design a combined form and to get it approved.

This whole "also affects" thing is incredibly confusing, and I came here to report a bug about it. Please clarify the following:

product
project
distribution
package

and how they relate to each other. For example, does a project have several packages?

The UI is very frustrating: for example, I want to mark the fact https://bugs.launchpad.net/ubuntu/+bug/198708 is related to https://launchpad.net/kde . I tried "also affects projects" and entered kde, and got an error saying "There is no project in Launchpad named "kde". Please search for it as it may be registered with a different name." . Searching for it in the dialog box provided leads to the very annoying error message "Too many matches. Please try to narrow your search." . It's just KDE, how can I narrow my search?

I've had similar issues when I had reported a bug for ubuntu-website ( https://bugs.launchpad.net/ubuntu-website/ ) and I wanted to mark it as affecting Ubuntu too. Same error, "There is no project in Launchpad named "ubuntu". Please search for it as it may be registered with a different name."

Ubuntu is one of the major projects/products/whatever-you-call-it on Launchpad, and if I search for it, I should get it. Surely Launchpad's search cannot be that bad?

Prateek, in Launchpad terms, KDE is not a project; the relevant project for bug 198708 is KTorrent <https://launchpad.net/ktorrent>. (Even if other applications have the same problem, unless the same patch could fix the bug in multiple applications, there should be separate bug reports for each application that has the problem. Use a tag to track them together, if necessary.) Projects may be linked to packages <https://launchpad.net/ktorrent/+packages> for ease of bug filing, but all packages belong to a distribution <https://launchpad.net/ubuntu/+search?text=ktorrent>. Distributions are treated as projects in a few places <https://launchpad.net/projects/?text=ubuntu>, but not others (primarily this bug and bug 80902). "Product" is an obsolete term for project; if you find it used anywhere in the Launchpad interface, please report a separate bug. Thanks.

I think this can be fixed by creating a first step that asks the user to choose a project (product/distribution) If the choice is a project continue along the project path, otherwise show a revised +distrotask that asks for just the package and url.

+distrotask does a few things that is wrong and we can fix this now.
1. Most of the distros listed do not use Lp to tack bugs. They should not be listed
2. Lp should only ask for packages when it knows that there is publishing information.
   If the user chooses a distro that uses bugs but does not have packages, do not ask for the package.

Agreed Curtis, a two-step process would work for this. But we could also
just have a project/distro picker which lets you pick either an upstream
or a distro. In the case of a distro, you may also want to pick a package.

Mark

Agreed. We just tested a candidate design: http://people.canonical.com/~curtis/target-picker/ We exploring how to implement it now.