Re: derivatives and bugs
On Mon, Sep 24, 2012 at 1:25 AM, nick black wrote:
> OK, so as I expected, further integration requires per-bugtracker support.
> I'd be interested in adding Bugzilla support, but I doubt I'm the best
> person to do so -- I'm much more a low-level guy, and really don't
> understand the world of presentation and webapi's very thoroughly.
> Switching from Bugzilla is not a very attractive option for us, especially
> if the switch is to something lacking dependency tracking. This kind of
> integration sounds desirable, though not so much that we'd change
Interesting, I hadn't thought of adding Bugzilla support and I note
that there are a wide variety of bugs in Bugzilla installations linked
to from the wiki. Had a quick look at the XMLRPC API docs, adding this
is probably 10-20 lines of python code so I'll work on that.
> So, it seems the Bugzilla XMLRPC API ought meet the machine-readable
> criterion. What data and schema are necessary for a "binary to source
> package mapping?" Is there an API which a Bugzilla (for example) query agent
> would conform to, or would this involve deeper DBX/DBTS hacking? I'm very
> interested in DBTS integration due to both the informative and marketing
> value, and Sprezzatech would be willing to fund the 10 hours of development
> I imagine necessary to write a Bugzilla query agent.
It looks like the Bugzilla XMLRPC API doesn't support searching, but
buglist.cgi seems to support various output formats, including RDF,
CSV etc. So basically we need a way for you to attach Debian source
package information to bugs. I guess the way to do that would be
through keywords, for example debian-udev, debian-warzone2100,
debian-eglibc. Then we just do a keywords-based search returning the
keywords data in CSV format and count the number of bugs for each
debian-* keyword, then link to the buglist.cgi page for the keyword:
It seems that the downside to using keywords is that the bugzilla
admin is the only one who can create them and they have to be created
> I'd be worried about QA, though. Could such agents result in general DBTS
> problems? I don't want to be responsible for hanging DBTS processes if this
> agent hangs, for instance -- again, see comments above regarding my fitness
> for this task.
I don't think that would be a concern, since the integration would be
between the PTS and bugzilla, not the BTS. The PTS is based on static
HTML so availability wouldn't be affected.
> I'd be more than happy to do this, and it looks like a good stopgap
> solution. Thanks for the pointer.
> Looks like a workable schema, pabs.
Thanks, I will document this in the derivatives guidelines.