Launchpad itself

Forwarding bugs for Ubuntu packages upstream takes much more time and effort than it could/should

Bug #587306 reported by Tomasz Chrzczonowicz
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
Low
Unassigned

Bug Description

===The Problem===

The current process of forwarding bugs upstream:

1. Read https://wiki.ubuntu.com/Bugs/Upstream, if you haven't already.
2. Read https://wiki.ubuntu.com/Bugs/Watches, if you haven't already.
3. Report bug on Launchpad.
4. Search for upstream bug tracker for matching bugs.
5. Set up an account on the upstream bug tracker, if you haven't already.
6. Log into upstream bug tracker.
7. Create a new upstream bug report
8. Copy and paste the description from Launchpad
9. Copy and paste a link to the Launchpad report in the bug description and/or in some form field
10. Switch back to Launchpad, click "Also Affects Project" and copy and paste the upstream bug URL into Remote Watch field.
11. Download attachments worth including in the upstream report
12. For each attachment, attach it to the bugzilla report
13. Write a comment to the user that their report has been sent upstream. (If you're forwarding someone else's bug)
14. Mark the bug's status and importance as appropriate

Results:

1. Takes more time that it could and should
2. Isn't easily discoverable
3. So people don't and won't do that.

From https://wiki.ubuntu.com/Bugs/Upstream :

Bugs that need forwarding to the Upstream bugtrackers:
https://bugs.launchpad.net/ubuntu/+bugs?field.status_upstream=pending_bugwatch&field.status_upstream-empty-marker=1

Unlinked upstream bugs - Sometimes people add a link to an upstream bug tracker in the comments of a bug but don't bother creating an upstream task. This is a list of possible targets that can be linked. (Lots of low hanging fruit in this list, but also a bunch of dupes and ones inappropriate to be linked.) : http://qa.ubuntu.com/reports/launchpad-database/unlinked-bugwatch.html [This particular aspect of the problem is already covered in bug #333215 and/or bug #420353]

===Solution===

The process could have only 3 steps:

1. After you report/triage a bug for an Ubuntu package in Launchpad, there is a button in the "What Next" section that says "Push Upstream!" or "Forward Upstream!"

2. Search results for your bug title are pulled from upstream bug tracker and slide out or pop up in a window, so you can check if it was already reported (Something like what your already have when reporting bugs in Launchpad). It has two buttons:

*New Report - you press it, when there is clearly nothing like your bug reported upstream.

*Link Reports - when there is an upstream report for your bug, but it's not watched in Launchpad. You pick one/several using a radio button/checkboxes.

3. Upstream Bug Tracker Authentication. One of the three:

[WORST] You're taken to the upstream bug tracker login page to enter your credentials. You need an upstream bug tracker account.

[SLIGHTLY BETTER] You're taken to your Launchpad/Ubuntu SSO OpenID authentication page if upstream bug tracker accepts OpenID.

[BEST] Launchpad has a its own upstream bug tracker account, say <email address hidden> and uses that automagically, so you don't have to create your own account.

At this point, Launchpad could take care of the rest in fully automated manner. I.e:

1. It creates an upstream bug report,
2. Links it to one in Launchpad
3. Sets up watching it from Launchpad.
4. Maybe adds Launchpad bug subscribers to CC list of upstream bug report.

Obvious tasks:

1. Mappings from Ubuntu packages to upstream bug tracker components. But it only needs to be done once and currently users have to do it individually each time they forward the bug.
2. Scripts to query/search upstream bug trackers for duplicate/linkable bug reports.

See original description
Revision history for this message
Graham Binns (gmb) wrote :

This is definitely something that we want to do in the future, and we've started part of the way along the road to this with the Trac [1] and Bugzilla [2] plugins (the Bugzilla API, v3.4+, is similarly useful in this respect).

I'm going to triage this as medium since it's something we want to do in the long term but won't be able to get to for a while due to other things that we need to focus on.

 [1] http://launchpad.net/trac-launchpad
 [2] http://launchpad.net/bugzilla-launchpad

Changed in malone:
status: New → Triaged
importance: Undecided → Medium
tags: added: bugwatch
Revision history for this message
Bryce Harrington (bryce) wrote :

The "Unlinked upstream bugs" issue in this bug report sounds perhaps like bug #333215 and/or bug #420353.

tags: added: better-forwarding
description: updated
Revision history for this message
Bryce Harrington (bryce) wrote :

I know that having to register in the upstream tracker is a major annoyance, however it's not something that should be worked around in launchpad. It would make life a bit harder for upstream folks - they couldn't query bugzilla to get a listing of all bugs you've reported for example. I suspect were we to add this, upstreams would invariably choose to block the account.

The OpenID approach is the only realistic solution. Honestly, they ought to be moving to OpenID just as a matter of course, regardless of launchpad. The underlying issue here is not launchpad making things harder, but rather bug trackers each requiring their own login authentication. I also suspect it's inevitable that bugzilla will gain OpenID support eventually.

So, I don't think we should waste any energies working around it at the launchpad level.

Revision history for this message
Bryce Harrington (bryce) wrote :

On re-reading my previous comment, it unintentionally came out a bit combative. Sorry about that.

Actually, for me the bug forwarding process is my #1 top wish for launchpad, and an area I hope to make some improvements in myself. This bug report is an excellent summary of all the problems, and serves as a good checklist of things that need attention.

But it's a big problem, and we need to boil it down to smaller, more digestible chunks in order to make some advancements. So anything we can reasonably cross off will help get it down to a more actionable scope. :-)

Revision history for this message
Bryce Harrington (bryce) wrote :

Items #1 and #2 (reading wiki pages) ideally should be irrelevant - any info that we would expect a bug forwarder to know ought to be obvious within the process. In any case, I think most people just don't read directions anyway, so we should keep the guidelines from those pages in mind as the feature is improved, but drop any expectation of users to read the pages before forwarding bugs.

Revision history for this message
Bryce Harrington (bryce) wrote :

Item #4 may or may not be worth doing. In the case of the X.org bugzilla at freedesktop.org I've found it is not worthwhile to search for duplicate bugs. Too often (at least with hardware bugs), one person's symptom looks much like anothers, and it's quite hard to definitively prove it as a dupe.

Rather, I just forward the bug upstream and focus on trying to make it as clear and complete as possible, and let upstream decide whether or not its a dupe. In bugzilla, like in launchpad, duping is fairly easy.

For other projects, like GNOME or OpenOffice.org, it's possible that searching for dupes upstream may be worthwhile.

In any case, I mentored a Google Summer of Code student who wrote a prototype upstream-bug-searching tool, that could give a jump-off-point for anyone wanting to work on solving this item:

http://bazaar.launchpad.net/~arsenal-devel/arsenal/master/annotate/head%3A/scripts/match-upstream.py

Revision history for this message
Bryce Harrington (bryce) wrote :

From my own bug forwarding practices, there are some additional steps:

11. Download attachments worth including in the upstream report
12. For each attachment, attach it to the bugzilla report
13. Write a comment to the user that their report has been sent upstream. (If you're forwarding someone else's bug)
14. Mark the bug's status and importance as appropriate

description: updated
Revision history for this message
Bryce Harrington (bryce) wrote :

For item #13, I use a 'stock replies' script from the launchpad-gm-scripts package to put a cookie-cutter reply for the user. It is able to get the upstream bug link from the remotewatch and include it in the reply.

Revision history for this message
Bryce Harrington (bryce) wrote :

For steps 11 and 12, we have a prototype script to automate these actions:
http://bazaar.launchpad.net/~arsenal-devel/arsenal/master/annotate/head%3A/scripts/send-attachments-upstream.py

Robert Collins (lifeless)
Changed in launchpad:
importance: Medium → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.