bug imports require admin intervention
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
High
|
Unassigned |
Bug Description
Bug imports are currently done by hand:
* User files a question against malone.
* If an XML bug dump is not linked to from the question, we must
request it, and point the user to trac-launchpad-
just the XML spec on the wiki.
* Import into a locally running Launchpad instance.
The XML produced by trac-launchpad-
requires some fixes, like changing bug nicknames, adding the
correct namespace. I've not seen XML from anyone else trying to
implement the spec independently for another bug tracker, but I
imagine there will be lots of teething pains.
This often means that there is a lot of toing and froing between
the requesting user and the Launchpad engineer.
* Optionally, a demo instance is started on EC2 to show the user the
results.
* Import the bugs into staging.
This can also highlight issues with the import data, so more toing
and froing.
It can also conflict with the availability of the LOSAs. If they're
busy - and they often are very busy - getting the bugs into staging
can take a day or more.
* Import the bugs into production.
Again, this can conflict with LOSA availability.
This is a *HUGE* time sink. We should make this whole process
self-service, so that engineers are only interrupted when something
goes wrong.
Such a service only needs to be available via the API. Upload XML to
the librarian, with a method call via the API from a project owner to
trigger the import. The import can take some time, so should run as a
job, reporting via email.
Also, trac-launchpad-
into Launchpad via the API when possible.
summary: |
- Make it possible to import bugs into Launchpad via the API + Enable self-service bug imports into Launchpad |
summary: |
- Enable self-service bug imports into Launchpad + bug imports require admin intervention |
tags: |
added: bugs canonical-losa-lp chr feature removed: lp-bugs |