On 26/07/08 at 22:23 -0700, Don Armstrong wrote: > 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.
There are many cases where it's easier/more efficient to have a local, summarized copy of the BTS summary data, like the bts2ldap dump. Basically all use cases that involve going through all bugs. A simple query that cannot be answered easily with the soap interface is: for each package, give me the number of open bugs tagged patch. We are trying very hard to stay as close from the BTS as possible (ideally, we won't have our own copy of the Debbugs modules, but use the one from the BTS directly). So that we can minimize the risk of having a different understanding of something (for example, bts2ldap doesn't call bug_presence(), and use a local cache, while we just use the Debbugs interface.) -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
