Don Armstrong schrieb: > On Wed, 14 Oct 2009, Bastian Venthur wrote: >> I'm trying my best to parse the SOAP replies provided by debbugs, >> but now I'm kind of stucked. >> >> A general and probably very easy question first: what is the difference >> between: >> >> fixed_versions and fixed >> found_versions and found > > fixed and found are hashrefs which indicate when a bug was marked > fixed and found; currently that's not implemented, so they are > hashrefs which have a key of the version, and a value of ''. > Eventually I'll probably make it work, though. > > fixed_versions and found_versions are arrayrefs which just have the > version that things are fixed and found in. It's probably what you > actually want.
So does that mean fixed_versions contains only *one* (the first) version where the bug was fixed and fixed contains all versions? Then the name fixed_version*s* would be a bit misleading (and also being an array :) -- if not, again, what would the difference between fixed if fixed would be implemented? Both should then contain all the versions where the bug was/is fixed, right? > >> id and bug_num > > These are the same; it's basically repeated because some things in the > code refer to a bug by id, and others by bug_num. I'm going to be > standardizing on bug_num, so if you can avoid using ID, that'd be > optimal. Ok, then I just leave out id in future releases with reference to this mail. > >> summary and subject -- here also: why is summary always empty? > > It's not, actually. See > http://www.debian.org/Bugs/server-control#summary and FE: > > $ bts status 441151|grep summary > summary It's already fixed in my tree and will be fixed in the BTS the > next time that I sync things up. Thanks! > >> The second and currently most urgent question: Some fields like >> "found" are very hard to parse. Usually found is a dictionary >> (pardon my Python :) containing a key "item" which contains a single >> or a list of dictionaries containing a "key" key which has the >> version as value. > > Vice versa, actually. The version is the key, and the timestamp at > which the version was marked or the empty string is the value. Ok, I'll have a look at it again from this direction. One last question for now: This is the list of all attributes a bugreport can have, could you quickly mark all those with an X which are currently not correctly implemented (like fixed and found) or superfluous like "id": fixed_versions: fixed: fixed_date: found_versions: found: found_date: keywords: tags: subject: summary: source: package: done: unarchived: archived: location: id: bug_num: blockedby: forwarded: msgid: ownwer: originator: date: log_modified: pending: blocks: mergedwith: severity: affects: I will try to update http://wiki.debian.org/DebbugsSoapInterface upon this data. Thank you very much! Bastian -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
