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

Re: Questions about BTS SOAP interface "pending" attribute



On Fri, 07 Sep 2012, Justin B Rye wrote:
> Don Armstrong wrote:
> >   get_bug_status
> [...]
> 
> Okay, so technically *all* of these elements (including the tags and
> subject and so on) are part of the bug's "status", and the "pending
> state" is just one element in that.

Right.
 
> >        pending -- pending state of the bug; one of following
> > possible values; values listed later have precedence if multiple
> > conditions are satisifed:
> 
> I hadn't guessed that! I was assuming a bug could have multiple
> state-tags at the same time... not that I'm saying any of this is
> unreasonable, just that it's not something anyone could have deduced
> from first principles!

Yeah, it's just the way it's always been done, and inertia is
difficult to overcome unless there's a strong reason to do so.

> >            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
> 
> This ordering is really interesting - if a bug only exists in the
> amd64 arch, it starts off "pending" there and "absent" elsewhere; then
> if it's tagged forwarded and pending, only the latter is reflected
> here (in a really confusing way).  Then "fixed" trumps those, but only
> for the non-"absent" arch, while "done" trumps everything and applies
> even to  the i386 nonbug.

absent and done are mutually exclusive, so you can't ever not apply to
this distribution/architecture and yet be resolved. So the bug would
still be absent in i386, but done in amd64, for example.

> And there isn't a state on the end of the list for "archived";
> that's recorded separately.

Yes, because archival state is primarily a reflection of where a bug
is located (and its modifiability), not whether it's been properly
resolved or not. [The code isn't supposed to archive bugs which have
not been properly resolved, but it's possible for a bug to become
present in a distribution after it has been archived.]
 
> The difference between "fixed" and "done" is also a bit obscure, but
> this is one I was already aware of.

Right; this is YA limitation of using synonyms with precise technical
meaning.


Don Armstrong

-- 
"Because," Fee-5 explained patiently, "I was born in the fifth row.
Any fool would understand that, but against stupidity the very Gods
themselves contend in vain."
 -- Alfred Bester _The Computer Connection_ p19

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


Reply to: