launchpad development
Provide Link Between LP Package/Products and Bugzilla Components
Map Launchpad source packages and products to the correct Bugzilla Product/Component set in a remote bugtracker.
As an Ubuntu developer
I want to see the component filled in on the bug filing form
so that I don't have to figure out the correct component when forwarding bugs upstream.
As an launchpadlib API user
I want to look up what bugzilla component a source package is associated with
so that I can forward bugs upstream mechanically.
As an launchpadlib API user
I want to write a script to set what bugzilla component a source package is associated with
so that I can generate all my component-to-source_package mappings mechanically.
So:
- retrieve from an external Bugzilla the list of components for each of its products
- associate a Launchpad source package or product to a component
- provide a way for users to update these associations
- insert the Component name into the external bug filing form
- expose API calls to interact with this data programmatically
Rationale
Bug upstreaming is a key part of the development process at Ubuntu. Users like using Launchpad for reporting bugs, and thus many are filed which really are upstream issues. Ubuntu developers fix some bugs, but the distro team simply lacks manpower to address every bug that gets reported. Thus it is vital that these bug reports get communicated upstream so that the right people can work on them. For this reason, the simpler the bug forwarding process can be made, the higher volume of bug reports can be forwarded, and the higher the quality Ubuntu can gain from its upstreams.
Why now?
Bryce has posted a prototype of a bug upstreamer tool[1] that goes beyond what Launchpad's bug filing form does. Ultimately, we want to enable analogous functionality inside Launchpad itself. This LEP is a first step towards this goal.
This is also being done, even if it's out of scope for our current priorities, because this is one of Bryce's goals for his rotation on the Launchpad bugs team, to get some part of this work into Launchpad itself and leave a foundation where this work could continue after he returns to Ubuntu Platform.
What value does this bring?
Currently, mapping source_packages in Launchpad to products/components in Bugzilla is hard, because there is so much variation in naming schemes between the two bug trackers. The bug filing form sidesteps this by simply requiring the user to select the component at point of bug filing. Sometimes this is easy, sometimes this requires extra knowledge that an ordinary user might not have. However, the mappings are 1-to-1, so is something that Launchpad can do, thereby removing one manual step from the process.
Furthermore, Bryce's prototype also lacks this mapping functionality, and just achieves it through some limited package-specific heuristics. Providing the mapping functionality as API calls will thus also enable his prototype to be more useful by using the package mapping in Launchpad itself. Or in other words, it is an incremental step towards implementing functionality for the prototype into Launchpad itself.
Stakeholders
Who will care about this work?
In particular, Ubuntu developers who frequently forward bugs upstream.
- bryce
- pedro
- jcastro
- JFo
- nigelb
When did we last talk to these stakeholders?
The prototype was presented at UDS Maverick in a session held by jcastro to discuss improvements to the bug upstreaming process. This was discussed in relation to the following Ubuntu blueprint:
https://blueprints.edge.launchpad.net/ubuntu/+spec/community-m-launchpad-upstream-improvements-bugs
Bryce and Deryck also talked extensively about this at the Launchpad Epic.
Constraints
This Feature Provides
- Bug filing form will cause the Bugzilla Component to be selected in the upstream bug filing page, if known
- Configuration page for adding/editing/deleting links of components to source_packages and products
- API calls for the following actions:
- list the products for a bugzilla
- list the components for a product in bugzilla
- return the source package for a given bugzilla component
- set the source package for a given bugzilla component
This Features Does Not Provide
- Support for bug tracker types other than Bugzilla
- Support for filling in any data other than Component
Workflows
Project Page
Configuring the upstream component for a package:
- On the project page for the upstream for a given package, user clicks "Configure bug tracker"
- User specifies one of the bugzilla instances for "In a registered bug tracker"
- User enters the Product as the "Project ID in bug tracker"
- User enters the Component as the "Project Component" field
- User clicks Change to store the new preferences
Bug page
Forwarding a bug for a package with a known upstream component:
- A user clicks "Also affects project"
- On 'Confirm project' page, user clicks the "bug filing form" link.
- The Component is passed as a GET parameter, and the Component selector automatically set to that value
- The user proceeds with filing the upstream bug
Success
How will we know when we are done?
When the bug filing form is correctly inserting the component field, and when Bryce is able to add support for using launchpad's source_package to component mapping in his prototype upstream too.
How will we measure how well we have done?
In theory, this should make it a tiny bit easier to upstream bugs, which might be measurable via an uptick in the rate of bugs being forwarded upstream. So some stats we could do include:
- Tracking the number of bugs filed upstream (as opposed to just watches created)
- Tracking the number of upstream components we have entered locally
- Tracking the number of links created between upstream components and lp packages/products
Notes
1: The prototype is currently hosted at http://www2.bryceharrington.org:8080/cgi-bin/send_upstream.cgi
