Paul Wise left as an exercise for the reader: > On Sun, 2012-09-23 at 02:23 -0400, nick black wrote offlist: > > ps feel free to reply to the list, quoting this as appropriate > Doing that since it gives me an opportunity to discuss some other things > related to bugs and derivatives that will allow us to expand the > derivatives guidelines on that topic. Great, I was hoping as much. > http://wiki.debian.org/Derivatives/Guidelines#Bug_reports > This is currently enabled for Launchpad and bugs.debian.org. 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 bugtrackers. > http://wiki.debian.org/Derivatives/CensusQA#Bug_links_on_the_wiki > http://wiki.debian.org/Derivatives/Integration#Status > having their bugs linked to from the PTS pages for each package and > willing to implement a machine-readable way for the PTS to know which > packages have bugs and where to find them? > http://wiki.debian.org/Derivatives/Integration#Bugs 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. 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. > That link isn't currently used by the census tools, it is informational > and mainly there as a way for people interested in specific derivatives > to find out how those derivatives would like Debian to change. Thanks for the info. > So if all derivatives were to use the usertags mechanism, we could > create some stats and graphs by querying this data. Nick, would it be > possible for you to start using usertags? Basically when forwarding bugs > you would add a couple of pseudo-headers. You would also need to mail > the control bot to add usertags to bugs you already forwarded. > http://wiki.debian.org/bugs.debian.org/usertags I'd be more than happy to do this, and it looks like a good stopgap solution. Thanks for the pointer. > I also wonder if we should have a standard set of usertags, something > like this perhaps. Probably no reason for derivatives who are already > using usertags to change to this scheme though, especially since debbugs > does not currently support changing usertags on archived bugs. > debian-derivatives@lists.debian.org > > origin-sprezzos > patch-sprezzos > release-sprezzos-foo > feature-sprezzos-foo > transition-sprezzos-foo Looks like a workable schema, pabs. I'm going to look into the details of your suggestions, see what I can automate with regard to Sprezzabugs, and get back to the list sometime this week. Thanks for your informative and thought-out reply! --rigorously, nick -- nick black http://www.sprezzatech.com -- unix and hpc consulting to make an apple pie from scratch, you need first invent a universe.
Attachment:
signature.asc
Description: Digital signature