Bug#374104: apt-listbugs
# Change 323626 to serious as per reasoning below:
severity 323626 serious
thanks control
On 7/11/06, James Westby <jw+debian@jameswestby.net> wrote:
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.
If you don't mind, I'll apply them one by one, just to make sure, it's
not that I don't trust you, it just means I can make sure that they
are properly in etc and can say for sure, as maintainer that they
*are* fixed.
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.
If your talking about the old script, I can get you links to it, but
seriously, it's just a couple of copies from /org/bugs.debian.org/
If your talking about the new script, which has not been designed yet
(from my knowledge), then I am assuming that Andreas will release it
to the community, and if so, i'll actually package that with
apt-listbugs (as a seperate package if need be).
>
> 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).
I'd have to look at the bugs again fully, but from memory they are
correctly labeled, there is one here that should be marked as policy,
which I have set in this email. (It's basicly a clone of this one, but
RC none the less).
>
> 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.
I'm sure we'd have more #374104's due to peoples lack of reading
READMEs, a better option in my opinion, is have the message, which can
be disabled after the first run. As in, say
<apt download actions here>
W: apt-listbugs data may not be current due to technical limitations
on the data host, to read more about this, and for instructions to
disable this message please see /usr/share/doc/apt-listbugs/README
<continue>
Of course, I will have to change the warning message to better suit
the various languages.
James
--
James Westby
jw+debian@jameswestby.net
http://jameswestby.net/
Hope this reply covers everything that I had not mentioned before.
--
N Jones
Reply to: