On (11/07/06 08:19), Nigel Jones wrote: > So, far I have been attempting to incorporate your patches into the > code, but I have decided to start from scratch again, and try and kill > the RC bug (334697), I have been in contact with Aba (Andreas) and we > should have some fresh data files built (based off the output of > bts2ldap), I'm sure it can be easily phased by apt-listbugs with a bit > of work.
apt-listbugs shouldn't need much modification unless you modify the format or location of the files. I'm sure your work will go a long way to fixing all of the problems though. Again, I'll say that I have a complete source package with all of my modifications included that you could use as a base. The modifications are away form the version-tracking and bug-handling code for the most part, so changes should be easy to handle. I'm unsure about the wisdom of having the code that generates the files not publically accessible, as this to me seems like part of the source of apt-listbugs. I'm sure that there is no legal argument to that effect, but it seems to go against the spirit of the project. It also hinders contributions, as only a few people can see the code and so diagnose bugs in it, and provide patches that might have been able to fix the problem long ago. Perhaps this is something you could consider as maintainer of the package. > > The code which i've seen (on the qa.debian.org side), is just making a > copy of all the .status files from the bts spool, which I believe > sometime soon are going to be no more, which seems to suggest that a > complete rewrite of the checking side of the program. This might be a good idea anyway. From what I have seen these files are the source of the bugs related to this, and the reason the package is RC buggy in the first place. In my opinion most of the important bugs should also be RC, but it's not my place to elevate them (though most will probably be fixed along with the RC one by the same changes). > > Sadly however, it may not be possible to run the code at say midnight > when the archive gets updates, due to what I am told is already busy > load on qa., so we may need a message in listbugs stating that the > data may be upto 12/24 hours out of date, we'll get to that when we > come to it. This makes sense, though I'm not sure it needs to be runtime output, it could just be in README and perhaps the package description. James -- James Westby [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
