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

Re: Question regarding debianbts' SOAP



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


Reply to: