I highly recommend subscribing to debian-lint-maint if you're interested
in doing work on Lintian or even just want to follow its development.
https://lists.debian.org/debian-lint-maint/
Copying this message there, since that's the right place for the
discussion, I think.
Louis-Philippe Véronneau <
pollo@debian.org> writes:
Hello!
Would people be against an effort to clean old and unused lintian tags?
I'm currently counting 1522 tags and I'm sure a bunch of those aren't relevant anymore.
Last time I tried to submit a MR where I was removing code I knew wasn't needed anymore, there was some push-back. Before I start putting energy
into this, I was wondering if people had opinions/advice.
What I was planning to do was to:
1. use the UDD database to list all the tags that aren't currently
emitted in the archive.
2. have a look at them and see if the issues they were flagging are still relevant.
I'm certainly not an expert in all the issues in the world, but I (maybe naively) thought certain things would stand out as being clearly "old
issues we don't care about anymore".
The final goal is of course to make lintian easier to maintain in the
long run, and maybe even faster?
Thoughts?
I am in general in favor of deleting code. However, I think there are a
few important caveats:
1. Most Lintian tags historically were extremely cheap to check and to
maintain, and I suspect this is still true with the new refactoring.
The main cost is the cost to run the test suite, and while that's not
nothing, it doesn't have lots of direct impact on development.
Just removing a random tag therefore probably doesn't help maintenance
a lot, but removing a tag that requires doing expensive searches or
(particularly) one that gathers information that isn't otherwise needed
or has complex analysis code that can be deleted entirely is very
valuable. I'm not sure if you can find any of those, but if you can,
that would be great.
2. You'll want to exclude autoreject Lintian tags. This is obvious when I
write it out, but it may not have immediately come to mind. Those tags
will never trigger in the archive because that's the point of them.
3. There's some merit in ensuring that recently-fixed problems aren't
reintroduced, so probably best to not remove a tag immediately after
the last package triggering it has been removed from the archive, but
wait a release or so until there aren't remnant packages or
documentation that might lead someone to reintroduce the tag.
Personally, I think the most valuable tags to clean up are not the tags
that never trigger, but instead the tags that have huge numbers of false positives. Those are the ones that eat up more maintainer time, both
Lintian maintainers and other package maintainers.
For example, the top of my list to remove would be very-long-line-length-in-source-file. I think the rationale for adding it
in the first place was well-meaning but misguided, every time I've
personally seen it trigger has been a false positive, and now its
existence is prompting people to spend time writing additional exceptions
and screens for it to try to cut down on the false positive problem. That
to me is an active maintenance problem for Lintian.
My impression is that the last few years saw a flurry of new tags added,
and some had dubious rationales and extensive false positives. My
philosophy back when I was the primary maintainer is that false positives
from Lintian were very bad, since they discourage people from using the
tool at all, and tags that are inherently impossible to stop from
generating false positives are dubious and probably shouldn't exist.
I'm possibly too aggressive on this front because I like to keep my
packages fully Lintian-clean (including pedantic tags) and therefore find
false positives personally annoying, but it may be at least worth taking a
look around and seeing what tags are issued for very large numbers of
packages, particularly if they're also frequently overridden.
(All of that being said, one of the problems with Lintian development
right now is that the test suite takes an excessively long time to run,
and it would be nice to improve that. I'm dubious that we can delete
enough tags and thus tests to make a huge difference, but it does help.)
--
Russ Allbery (
rra@debian.org) <
https://www.eyrie.org/~eagle/>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)