Re: Plans for squeeze
Russ Allbery wrote:
> Raphael Geissert writes:
>> Russ Allbery wrote:
>
>>> I'm not sure about this one, honestly. I think there's something to be
>>> said about the simplicity of this mapping, and we do make the
>>> additional information available in the long description. But maybe I
>>> just don't like change. :) I think getting more input on this would
>>> be good, though.
>
>> My concern is that the EWI code doesn't tell much, and a lot of people
>> ignore I tags just because they think they are not that important;
>> although most indicate some sort of bugs in the package.
>
> Well, I think people ignore I tags because they're not displayed by
> default, and they're not displayed by default because they're minor or
> wishlist bugs. I don't think the lack of information has anywhere near as
> much effect as not displaying them by default, which is intentional. Even
> if we changed the display format, I don't think we'd show them by default,
> at least without a lot of broader input.
>
> This is the standard dance around trying to get people to fix problems
> without being so picky that they just ignore Lintian altogether.
True. What about storing tags that were not issued due to -I not being
enabled, so that when only one package is being checked (imposing this
limitation so that there's no global var eating memory) and less than an x
number of tags were not issued (say only one W) some extra I tags are
included as well. Of course an extra option would disable that behaviour.
If only certainty > wild-guess and severity > wishlist are displayed
as "extra" tags, it would include the severity: minor, certainty: possible
tags. But if we limit the extra tags based on the severity only (i.e. >
wishlist), it would include:
severity: normal, certainty: wild-guess
severity: minor, certainty: possible
severity: minor, certainty: wild-guess
What do you think about that?
>
>>> I thought I responded to your patch with the specific details of what
>>> else needs to be done, and I hadn't seen a further response after that.
>>> Maybe Gmane dropped the message for some reason? The main change,
>>> IIRC, is that the package list format needs to be changed to include
>>> the archive area so that we can display that information on the
>>> lintian.d.o web pages.
>>
>> If that was the problem, I think I already addressed those in the last
>> patch I sent to the BTS[1]; you later sent [2] where you removed the
>> 'patch' tag.
>>
>> [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516530#57
>> [2]http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=59;bug=516530
>
> Oh, I owed you another reply. Sorry, didn't realize that.
>
> Looking at the last patch, though, I still don't see any sign of this
> change to the package list format. The only data being included is still
> just:
>
> + print OUT join(';',
> + $pkg,
> + $data->{'version'},
> + $data->{'source'},
> + $data->{'source-version'},
> + $deb_file,
> + $timestamp,
> + ),"\n";
>
> and:
>
> + print OUT join(';',
> + $pkg,
> + $data->{'version'},
> + $data->{'maintainer'},
> + $data->{'uploaders'} || '',
> + $data->{'architecture'},
> + $data->{'standards-version'},
> + $data->{'binary'},
> + $data->{'files'},
> + $dsc_file,
> + $timestamp,
> + ),"\n";
>
> which doesn't include the archive area. Am I missing something?
>
No, not at all. I missed that part, although I did modify
lib/Read_pkglists.pm so that it could read that info. I'll make those
changes and re-send it to the BTS. Thanks for reviewing it.
>> Forgot to mention: I think the easiest way, for now, to support
>> multi-arch lintian labs would be by generating a lintian.log for each
>> architecture being tested. The rationale is that neither the internal
>> nor external (non-lintian) infrastructures support multi-arch output
>> (they all use EWI code which, again, lacks important information).
>
> Right, the output format doesn't include the architecture of the package.
> I think that generating multiple lintian.log files is the right thing to
> do anyway, since you don't actually want to display the merger of them
> all. You want to do duplicate suppression first, and if you're going to
> do duplicate suppression anyway, it's just as easy to do that from
> multiple logs.
Sure, just wanted to get an ok.
>
>>> Yeah, we should figure out what to do with that stuff. I don't know if
>>> debcheck in particular has anything to do with the version that's being
>>> run across the archive or whether it should.
>
>> AFAIK debcheck (qa.d.o stuff) != depcheck; and debcheck is written in
>> python and lives under qa's svn repository.
>
> In that case, is there any reason not to just delete depcheck? Last time
> I looked at it, it was extremely incomplete and would require a lot of
> work to do something useful.
>
Yeah, what I meant with source tree cleanup was more or less a proposal to
git rm stuff :)
Cheers,
--
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net
Reply to: