Can't target bug report from project to distribution, or vice versa

Escalated to the stakeholders list by James W.

We may be able to repurpose the target widget used by questions. There are some nuances, that needs investigation--bugtask types mapping to bug target types. The it supports project or distro or distro source package.

Since the goal is to enable retargeted using ajax, a new widget is needed. Given the confusion about the existing retargeting widget used by answers. A multi-step process may clarify the steps. The user can search the ProductORDistribution vocab and choose one. If the user chooses a distro, the next step suggest the user choose a source package.

This first requires fixing BugTask.transitionToTarget to allow these moves. I'm not sure why it is currently restricted -- possibly to slightly simplify the required logic?

Surely its 'delete the old task, add a new one, done' ?

Deleting the old one and creating a new one would involve copying status, importance, assignee, milestone (if the new target has a milestone of the same name), creation date, and creator from the deleted to the new. Ideally it would also be obvious in the code that if you add anything new to BugTask in the future, that thing should also be added to the copy process.

I agree that relevant fields need to be copied across. My point was
more that transitionTo... really isn't a blocker.

This issue is more complicated than current discussion implies. Here are some issues that came up in two aborted attempts to address this issue.

Retargeting a bug to Ubuntu is not good enough. There is very little chance that a bug targeted to Ubuntu will be properly triaged or ever fixed. A project bug needs to be retargeted to a source package. I am sure the user will not always know how to choose a source package, but the UI must provide this level of targeting to "move" a bug instead of placing a bug in limbo. Also not that you cannot retarget a bug to Ubuntu if Ubuntu or an Ubuntu source package is already targeted.

A two step picker could accomplish this but there are more complications, namely the package vocabulary is unusable. Searching for something like apt results in a "too-many-results" error. The vocabulary is prone to timeout. The packages do not have descriptions that inform the user about which to select...even if there is an exact match. The source package vocabulary and picker must be fixed first

The targeting to package scenario is not better. The project picker does not show me enough information to retarget a bug that contains sensitive information. for example, searching for "ubuntuone" shows me only two projects that are official to the projects, the other four are not. The picker needs to show me the Launchpad-Id, owner, maybe project group too to convince me that my decision is correct.

I have a cunning plan. The disclosure feature intends to address the trust issue with the picker. The vocabularies will be changed address sorting and relevance. This bug could be fixed as a part of that effort; If someone were to provide a patch that did allow proper retargeting today, the picker would still be reviewed and updated as a part of disclosure effort to provide trusted pickers.

On Wed, May 4, 2011 at 6:41 AM, Curtis Hovey <email address hidden> wrote:
> This issue is more complicated than current discussion implies. Here are
> some issues that came up in two aborted attempts to address this issue.
>
> Retargeting a bug to Ubuntu is not good enough. There is very little
> chance that a bug targeted to Ubuntu will be properly triaged or ever
> fixed.

However the default for a user filing a bug in the web UI is to file
it without a source package if they don't know one. Demanding a source
package would itself be a bug because users often don't know enough to
choose the source package. Its up to the distro triage process to
select the right source package : we can get the bug to them and let
them hand it off.

> A project bug needs to be retargeted to a source package. I am
> sure the user will not always know how to choose a source package, but
> the UI must provide this level of targeting to "move" a bug instead of
> placing a bug in limbo. Also not that you cannot retarget a bug to
> Ubuntu if Ubuntu or an Ubuntu source package is already targeted.

That sounds like a defect; bugs can have multiple ubuntu /
ubuntu-source-package tasks, so retargeting a task when there is an
existing source package/distro task seems fine per our model.

@Robert
However the default for a user filing a bug in the web UI is to file it without a source package

Not so, normal users cannot report a bug targeted against Ubuntu. The link to report a bug on
https://bugs.launchpad.net/ubuntu takes me to a wiki that explain how to report a bug using
ubuntu-bug or the apps help menu.

This also a contributing reason about why so many Ubuntu bugs are reported against the
launchpad project.

@Robert
That sounds like a defect; bugs can have multiple ubuntu /
ubuntu-source-package tasks, so retargeting a task when there is an
existing source package/distro task seems fine per our model.

I think you misunderstand. Yes Ubuntu can have multiple bugs represented
as task for many source packages. A source package cannot be listed twice
in the affects table...that would be duplicate. Nor can you add a new task
for a source package if only Ubuntu is affected. You can retarget the distro
task to the source package. An alternate workflow would be to delete the
distrotask and replace it with a source package task.

The general principle is refine the bug to a specific package or set of packages.
Generic targets like a distro do not provide the information needs to make a
fix.

On Wed, May 4, 2011 at 9:47 AM, Curtis Hovey <email address hidden> wrote:
> @Robert
> However the default for a user filing a bug in the web UI is to file it without a source package
>
> Not so, normal users cannot report a bug targeted against Ubuntu. The link to report a bug on
> https://bugs.launchpad.net/ubuntu takes me to a wiki that explain how to report a bug using
> ubuntu-bug or the apps help menu.
>
> This also a contributing reason about why so many Ubuntu bugs are reported against the
> launchpad project.

Ah yes, I'd forgotten about that brain damage.

Ok, so the specific case is 'if the desired target is already present
there is no sensible action to take' - but that seems its already
(crudely) handled by setting it invalid. We can limit discussion in
this bug to retargeting when the desired target does not already have
a task.

> The general principle is refine the bug to a specific package or set of packages.
> Generic targets like a distro do not provide the information needs to make a
> fix.

They don't, but $product developers moving a bug out from their
product may not know the right source package. Getting the bug one
step closer is better than not getting it closer at all. I agree that
we need to be able to do source package retargeting, I'm just saying
that choosing a source package shouldn't be mandatory.

I agree it cannot be mandatory. Forcing users to choose a random package to satisfy a form is also a bad experience.

Removing from the escalated bugs list since it's out-of-scope for that kind of items and will be tackled as part of the privacy work.

The model side is a little deeper than we imagined. There are marker interfaces and subscribers to take care of. But I'm nearly there.

r13489 in stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13489) is part of this bug's fix.

r13492 in stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13492) is part of this bug's fix.

r13494 in stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13494) is part of this bug's fix.

r13514 in stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13514) is part of this bug's fix.

r13529 in stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13529) is part of this bug's fix.

r13530 in stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13530) is part of this bug's fix.

r13531 in stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13531) is part of this bug's fix.

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

Thank you!