Re: usage of lintian as an automated and forced qa check tool
On Tue, Aug 05, 2008 at 09:50:04PM +0200, Joerg Jaspert wrote:
> as just discussed with djpig here at DebConf, we (as in ftpmasters/team)
> want to use lintian as an automated forced qa tool, no longer a
> voluntary one. At least for a certain set of tags.
>
> What we basically want is
>
> - ftpmaster selects a set of tags on which we autoreject on, we write
> them in a file, one by line.
>
> - process-unchecked, so the first step in the archive, uses lintian
> - if the defined tags are found - package is rejected.
> - there will be a seperate override-like set, so we (as in ftpteam)
> can define exceptions, if a package really needs to violate such a
> tag
>
> - on build time lintian should fetch the file of ftpmaster tags, so it
> can show a new F: tag to the user, basically meaning "Fuck off, dont
> upload, will get rejected anyways", publically named
> "Ftpmaster-reject" or similar :)
>
> - lintian gets a new commandline option, like --tagfile, and only runs
> checks that are needed to find the tags listed in that tagfile (i jut
> submitted a wishlist bug for this).
>
> This is a pre-requisite to another enhancement in the archive and as
> such to be planned to "be implemented soon".
>
> What are your comments on this?
Good. The main goal of the new Severity/Certainty classification was to
allow the use of lintian to reject packages automatically. It is a good
thing there are already plans to use lintian to autoreject (even if not
using the new classification at all).
Still, it would be interesting to know what kind of tags do you plan to
autoreject on. Perhaps your set of tags can be directly mapped to a
particular group of tags using Severity/Certainty. This way we could
avoid duplication and synchronization (e.g. new tags, changes in current
tags, fetching ftpmaster's tags file...). If it can't be easily mapped,
some adjustments could still be made. And if it is really needed, this
is not necessarily incompatible with a tags file. Just trying to
reduce/avoid as much as possible duplicate info and synchronization.
Reply to: