Linking to remote bug is very awkward

[Brad Bollenbach]

From lifeless:

> On a related note, 'Remote Bug Details' could do with some in-your-face
> help too.

I interpret this to mean that lifeless is reporting that it's not obvious to discover the RBD functionality (in particular, how to add the remote bug watch in the first place.)

But I'm only noting this in a bug repor...

The current workflow for linking a Malone bug report to a bug report somewhere else is quite awkward.
1. In the "remote bug watches" box, click "Add".
2. Choose the bug tracker and enter the bug number, and click "Add" again.
3. Click on the fix request most relevant to the external bug report.
4. From the "Remote Bug Details" menu, choose the watch you just added, then click "Save Changes".

Much better would be this:
1. Choose the bug tracker and enter the bug number, then click "Save Changes".

This would also let us get rid of the "remote bug watches" portlet.

See also <https://wiki.launchpad.canonical.com/BetterUpstreamHandling>.

[Christian Reis (kiko)]

We should be consistent in naming. If it's a bug watch, call it that (and not remote bug details). Using two terms to refer to the same thing is very confusing.

[Christian Reis (kiko)]

As I wrote in bug 5409:

Yeah, I think a URL is probably the way to go. It would involve parsing the URL, trying to locate a registered bugtracker with the provided hostname, and then using something like the dictionary in BugWatch.url() to grab the actual bug id.

[Henrik Nilsen Omma (henrik)]

I'll add my comment here since it's the closest thing I found, but it might be that it should be a separate feature request ...

In the Ubuntu Accessibility Team we are about to start on a grand program of a11y testing and bug reporting. Some things will be Ubuntu-specific, but often these will be pure upstream bugs that we will report directly upstream. Reporting them all locally would flood our local bug triggers too much. One example is the failure of applications to play nicely with the high visibility themes or not communicating properly with AT-SPI (the accessibility infrastructure that all apps should hook into). This could result in a pretty much identical bug being reported in 50 odd separate upstream projects. It would be nice to have a handy way of tracking how the upstreams are getting on with fixing these.

The first idea was to add the <email address hidden> address to the CC field of the remote tackers, but that could potentially generate a huge amount of traffic over time that could prove difficult to remove again. The next idea is to have a dedicated email address (at gmail, or preferably launchpad ...) that would be added to the remote tracker CC field. That way we could filter and throttle it later as needed.

Reading this bug, I'm thinking that CCing a project email might be a convenient way of adding a remote bug watch. This would be useful for projects like ours that will largely be following upstream bugs for some time. You might be browsing the OpenOffice BTS for a11y bugs and when you see one that you want to follow more closely you can simply add <email address hidden> to the remote CC field and it will automagically appear in our remote watch list for our project here at LP. If the bug is already being tracked LP would do the right thing (TM). Any comments or changes made to that bug remotely could then be read directly in LP. As a bonus, someone looking at the bug remotely would be able to tell by the CC that it is being tracked by a team in launchpad. Entering that email address into an LP search box should give you the list of bugs that gets notifications on that address.

[Brad Bollenbach (bradb)]

On 12/14/05, Henrik Nilsen Omma <email address hidden> wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/1208
>
> Comment:
> I'll add my comment here since it's the closest thing I found, but it
> might be that it should be a separate feature request ...
>
> In the Ubuntu Accessibility Team we are about to start on a grand
> program of a11y testing and bug reporting. Some things will be Ubuntu-
> specific, but often these will be pure upstream bugs that we will report
> directly upstream. Reporting them all locally would flood our local bug
> triggers too much. One example is the failure of applications to play
> nicely with the high visibility themes or not communicating properly
> with AT-SPI (the accessibility infrastructure that all apps should hook
> into). This could result in a pretty much identical bug being reported
> in 50 odd separate upstream projects. It would be nice to have a handy
> way of tracking how the upstreams are getting on with fixing these.

This is an interesting use case. Let me restate your requirements to
make sure that I understand correctly, and then we can decide whether
this information is related to this bug report or if it's a separate
discussion. It sounds like:

  * you want to report accessibility bugs in various upstream projects

  * you often don't want to track these problems in the related Ubuntu packages

  * you want to be able to get a list of these bugs in Malone

  * you want Malone to be synching in the status changes and comments
from these upstream bug reports

Does that sound right?

Cheers,

--
Brad Bollenbach

[Björn Tillenius (bjornt)]

You can now add a bug watch directly from +upstream, +distrotask, and +editstatus.