Importing RPM bugs from multiple trackers?

Asked by Jeff Johnson

Hi --

I'm the lead developer @rpm5.org for RPM.

I'm trying to use the Launchpad bug tracking system to
import bugs from multiple sources because of Launchpads
ability to automatically track state changes in foreign systems.

What is the easiest way to accomplish an en masse RPM bug aggregation
from multiple bug systems so that the bugs can be prioritized and dealt with?

Here are a few of the common bug reporting URI's for RPM that I'd like to aggregate:
    http://rpm5.org/tickets cvstrac
    http://rpm.org/ticket trac
    http://bugzilla.redhat.com bugzilla

(Note: Could you also see if its feasible to register the cvstrac system
at http://rpm5.org? That doesn't seem to be available as a type of tracker.
Thanks!)

Ideally I'd like to also to capture all rpm-based distro bugs, but that may
be a Sisyphean and useless task.

It appears possible to achieve an aggregation of RPM bugs manually, but it will
be a huge amount of noise as mails get sent and comments get added and more.
If manual bug re-entry is the only process, well, that works too.

I've prototyped (more-or-less) what I want to do with a few bugs registered
against the Launchpad RPM project, using CentOS as a distribution, and
attaching an external tracker to http://rpm.org/ticket.

But perhaps there is a better way to aggregate bugs from multiple sources?

Thanks for help!

73 de Jeff

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Jeff Johnson
Solved:
Last query:
Last reply:
Revision history for this message
Deryck Hodge (deryck) said :
#1

Hi, Jeff.

I'm not sure we can do what you want, though I may be misunderstanding your goal. The inter-tracking functionality of Launchpad's bug tracker is meant to coordinate efforts in a single bug. So if 3 developers from different projects are all working on the same bug, they could coordinate efforts via Launchpad (as one example use case). Our system is not really designed for the case of -- show me an aggregate view of all bugs across projects X, Y, and Z. As I understand your question, this is what you are trying to do, and we don't really support that now. Eventually we could be in a position to offer this kind of aggregate view, but currently we don't do this.

As for supporting cvstrac, we don't support this type of tracker. You could open a bug against malone here on Launchpad requesting us to do so. It would depend on how many people need cvstrac support before we would take on the work, but we would be happy to mentor anyone who wanted to add an external tracker type to Launchpad for cvstrac.

Cheers,
deryck

Revision history for this message
Jeff Johnson (n3npq) said :
#2

Thanks for the reply.

Yes what I'm doing is rather unusual. What I'm trying to do is gather
all open RPM bugs that exist on the planet earth (there's ~2000 afaict).

The next step will be to classify the bugs into blueprints, devise a fixit plan, and
then proceed through milestones to timelines to releases.

In short: I'm retrofitting this workflow for RPM

   bugs -> blueprints -> milestones -> timelines -> releases

So far Launchpad is doing the job fine. Its a bit tedious re-entering tracker bugs,
but that is a finite amount of manual labor for ~2000 bugs. But reclassifying
the bugs into blueprints is where my real cost is, and that cannot be easily reliably
automated.

I can live without @rpm5.org cvstrac in Launchpad too. The existing bug tracker @rpm5.org has
always been a bit clunky to use, and gray-on-black is really hard on my tired old eyes.

That was one of the motivations for finding a better bugtracker, and Launchpad as-is
is quite nice imho. A few quirks and details (all bugtrackers are quirky), but iLaunchpad is
 already saving me gobs of time that I used to spend hoping around to multiple repositories
and bugtrackers; the e-mail notification is easier for me to deal with, and I have the needed
URI's now wired up with project/distro tracking bugs to rapidly check status.

BTW, down the road a bit (like 4-6 months from now), I'm highly likely
to suggest that Launchpad start handling *.rpm packages as well as *.deb
packages. Just a gentle forewarning to let you know where I am headed ... ;-)

Thanks for the answer.