On Sat, 26 Jul 2008, Lucas Nussbaum wrote: > On 26/07/08 at 10:03 -0700, Don Armstrong wrote: > > On Sat, 26 Jul 2008, Lucas Nussbaum wrote: > > > Indeed, it did. I also fixed a few other bugs with exactly the same > > > problem, but there's another class of bugs with problems. > > > > This is the same class of problem. Fully qualified version strings are > > sourcepackage/sourceversion. > > > > > Found-In: udhcpc/0.9.8cvs20050124-3 > > ^-- this is not a source package. > > Oh ok, I understand now. I see that It should be: > Found-In: udhcp/0.9.8cvs20050124-3 > Package: udhcpc
Right. > I suppose that this was changed in the BTS at some point, since only > old bugs seem to be affected? There was a problem with the qualification of source versions for a while, but the format was always sourcepackage/sourceversion. > Would it make sense to write a script that would correct that info > for all bugs affected by that issue? Someone would have to check to make sure that all of the changes made sense before making them. [In general, things without a version information where the warning triggers should be fixed, but there may be cases where the version is correct, and we're just missing the versioning information.] > > That said, what are you guys actually doing when you're using > > Debbugs::Status directly? Almost everything should be calling the soap > > interface and not relying on copies stuck elsewhere. > > The goal is to import all bugs into a postgresql DB, so that it's > possible to use that info together with info from other sources. I'm > not sure that importing all bugs using SOAP really makes sense. > Also, we are not parsing the BTS data files directly, we are using > the Debbugs perl modules, so we should be relatively safe in case of > data format changes. The goals are similar to the bts2ldap > interface. In fact, I hope that this can replace the bts2ldap > interface (which is not really maintained, and contains some errors, > currently). Importing using soap would be silly, yes. What I really wanted to know was what you all were actually querying that the existing soap methods didn't work well. My main concern is avoiding multiple sources of failure, where someone is using a dataset which is not the BTS itself. That is, ideally all use of bts2ldap would be replaced by calling the soap methods directly. Don Armstrong -- I leave the show floor, but not before a pack of caffeinated Jolt gum is thrust at me by a hyperactive girl screaming, "Chew more! Do more!" The American will to consume more and produce more personified in a stick of gum. I grab it. -- Chad Dickerson http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
