Bug#1109680: release.debian.org: use lintian results to block testing migration
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.
A regression approach also means that a manual hint is needed when a
package that got removed from testing (sometimes by a release team
member to help a transition) wants to reenter - it already happens in
rare cases with binary-all packages not installable on arm64, but
lintian warnings are not rare.
It would make more sense to block unconditionally (regression or not)
on a whitelist of lintian errors the release team does not want to have
in the next release.
Or announce that migration will be blocked on all lintian errors after
the release of forky, only displaying the information in excuses until
then (similar to reproducible).
Regarding the implementation, instead of waiting on another external
service that runs lintian it might be an option that britney
automatically adds an superficial autopkgtest to every package
running something line "lintian --fail-on error".
> Paul
cu
Adrian
Reply to: