On 12/08/25 at 23:05 +0300, Adrian Bunk wrote: > On Tue, Aug 12, 2025 at 05:39:14PM +0200, Paul Gevers wrote: > >... > > > I saw the discussion about the number of tag occurences for a given > > > source package, that should be used to identify regressions. Tags are > > > currently only listed once per source. It would be possible to add the > > > number of occurences for each tag (with distinct "information"). Let me > > > know. > > > > Currently I'm only thinking of aliased-location, which we really want to > > prevent altogether, but in the future we might want to add things that > > shouldn't regress. But maybe we can delay that to when we get there unless > > you already have a good idea for that? > > I don't think a regression approach makes sense for lintian tags, > especially not for warnings. > > When a package has a new binary that does not have a manpage, > there is a new lintian warning. > > A missing manpage is a problem in a package that should be visible, > but I don't see how this could warrant blocking testing migration. > > If you block testing migration on that, you are forcing the maintainer > to hide the problem by adding a lintian override.
I understand that the plan is to block on a small subset of tags (which probably wouldn't include missing manpages). Lucas
