[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: derivatives and bugs

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

> 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

Reply to: