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

Re: Questions about BTS SOAP interface "pending" attribute

On Thu, 06 Sep 2012, Francesco Poli wrote:
> If my understanding of the four statuses is correct, it seems to me
> that their names are a bit misleading: while 'forwarded' and 'done'
> look basically OK to me, 'pending' seems a bit of a misnomer to me
> for a bug that is open, but not forwarded nor tagged "pending" (I
> would call it 'unfixed' or something like that); finally,
> 'pending-fixed' looks a bit awkward to me (I would simply call it
> 'pending', since it corresponds to the "pending" tag for open bugs).

It's this way for historical reasons, unfortunately. The names aren't
entirely logical, but changing them makes no sense. Since you asked,
and since I've been asked before, I just went ahead and documented
what get_bug_status returns, which is what Debbugs::SOAP calls and

            my $status = get_bug_status(bug => $nnn);

            my $status = get_bug_status($bug_num)


       bug -- scalar bug number
       status -- optional hashref of bug status as returned by readbug (can be passed to avoid rereading the bug information)
       bug_index -- optional tied index of bug status infomration; currently not correctly implemented.
       version -- optional version(s) to check package status at
       dist -- optional distribution(s) to check package status at
       arch -- optional architecture(s) to check package status at
       bugusertags -- optional hashref of bugusertags
       sourceversion -- optional arrayref of source/version; overrides dist, arch, and version. [The entries in this array must be in the "source/version"
       format.] Eventually this can be used to for caching.
       indicatesource -- if true, indicate which source packages this bug could belong to (or does belong to in the case of bugs assigned to a source package).
       Defaults to true.

       Note: Currently the version information is cached; this needs to be changed before using this function in long lived programs.


       Currently returns a hashref of status with the following keys.

       id -- bug number
       bug_num -- duplicate of id
       keywords -- tags set on the bug, including usertags if bugusertags passed.
       tags -- duplicate of keywords
       package -- name of package that the bug is assigned to
       severity -- severity of the bug
       pending -- pending state of the bug; one of following possible values; values listed later have precedence if multiple conditions are satisifed:
           pending -- default state
           forwarded -- bug has been forwarded
           pending-fixed -- bug is tagged pending
           fixed -- bug is tagged fixed
           absent -- bug does not apply to this distribution/architecture
           done -- bug is resolved in this distribution/architecture
       location -- db-h or archive; the location in the filesystem
       subject -- title of the bug
       last_modified -- epoch that the bug was last modified
       date -- epoch that the bug was filed
       originator -- bug reporter
       log_modified -- epoch that the log file was last modified
       msgid -- Message id of the original bug report

       Other key/value pairs are returned but are not currently documented here.

Hope that clarifies.

Don Armstrong

A kiss was mysterious and powerful, fragile and invincible. Like any
spark, a kiss might fizzle into nothing or consume an entire forest.
[...] A kiss could change the entire world.
  -- Scott Westerfeld _The Killing of Worlds_ p336

http://www.donarmstrong.com              http://rzlab.ucr.edu

Reply to: