On Thu, 6 Sep 2012 15:24:46 -0700 Don Armstrong wrote: > 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 [...] > > It's this way for historical reasons, unfortunately. Ah, I see. Thanks a lot for clarifying. > The names aren't > entirely logical, but changing them makes no sense. Agreed: interfaces should not get broken, unless there's a very compelling reason to break back-compatibility. I see no compelling reason to change the BTS SOAP interface. After all, in the present case, those names are something intended to be interpreted by programs and not directly by users (at least normally). Please correct me if I am wrong. As a consequence, the fact that apt-listbugs exposes those names to its users (since they are possible values for command line arguments) is a flaw of apt-listbugs. Maybe apt-listbugs should use less misleading names for the states when parsing command line arguments, and then internally map them to the historical names used in the SOAP stream. Please note that apt-listbugs already maps the historical names to more discursive descriptions for its output: "forwarded" becomes "forwarded" "done" becomes "marked as done in some version" "pending" becomes "unfixed" "pending-fixed" becomes "tagged as pending a fix" I could implement something similar for the (command line) input in apt-listbugs: "forwarded" would be mapped to "forwarded" "done" would be mapped to "done" "unfixed" would be mapped to "pending" "pending" would be mapped to "pending-fixed" However, this would break back-compatibility with possible user-written scripts that invoke apt-listbugs, so it should not be done lightly (and absolutely not during a freeze). I will think about it and possibly do it after wheezy is out... Please let me know what you think. Thanks for your precious insight! > Since you asked, > and since I've been asked before, I just went ahead and documented > what get_bug_status returns [...] That's very interesting. Could you please publish the BTS SOAP interface documentation in a web page or online document, to be made available on http://bugs.debian.org or in the official Debian web site in a DFSG-free manner under the same license as debbugs (GPLv2)? Or, in alternative, could you please contact all the copyright holders for http://wiki.debian.org/DebbugsSoapInterface and ask them to agree to license that wiki page under the same terms as debbugs (GPLv2)? It seems to me that the list of contributors is not huge: http://wiki.debian.org/DebbugsSoapInterface?action=info Hence, the licensing should be doable in a reasonable time-frame. Once the wiki page has been licensed in a DFSG-free manner, could you please update and complete it, so that it reflects the actual BTS SOAP interface? Thanks a lot for your time and for your useful help. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Attachment:
pgpTVIdFgzEDK.pgp
Description: PGP signature