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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
