Bug#1007002: lintian: transition to "pointed hints" has invalidated many overrides

2022-06-13 Thread Axel Beckert
Hi Simon,

Simon McVittie wrote:
> Control: unblock 1006348 by -1

Thanks!

> #1007002 was marked as blocking #1006348 "lintian: Tag
> improbable-bug-number-in-closes condition considers 7-digit bug numbers
> improbable", but I think that was a side-effect of the merge

Definitely. All three unmerged bug reports had that block.

> and I don't consider #1007002 to be RC or a blocker for #1006348, so
> I'm removing that metadata.

Actually it was still on my TODO list to find out which of the bug
reports was related to #1006348 and why. You reduced that part of my
TODO list to 2/3 by no more having to check this bug report. Thanks!
:-)

> > Since at least I will not revert such huge changes, I'll tag #1007002
> > as "wontfix" for now and downgrade it to its original severity.
> > 
> > We can continue working on that bug report if we find someone who
> > either will work on reverting all the related work (although I think,
> > it's both, too late and also probably way too much work given all the
> > other recent changes) or, probably much better, provide either a
> > migration script or some code which also accepts the old override
> > formats. In that case, I'd remove the "wontfix" again. (Sorry, Simon,
> > I generally agree with #1007002, but we currently have way more severe
> > issues with Lintian than #1007002. Hence I also didn't remove the
> > confirmed tag.)

Oh, JFTR: This refers to Lintian as it was in Git when I took over.
There are parts of that tag format transition already committed in Git
which aren't yet in Debian Unstable. :-/ There were nearly 200 commits
in git since 2.114.0 before I started working again on Lintian. I
won't triage and revert them either unless they are outright buggy in
a technical sense. Sorry. As mentioned it would need much more man
power to "fix" this issue, even with what is so far only in git.

And with Felix and Chris left the Lintian development, there's much
less man power so far. At least so far I'm the only one who did
commits since then, but there were at least three DDs asking for group
membership on Salsa (Thanks!), so I hope they will start working on
Lintian as well. I'm also updating the development how-tos where I
notice that they're outdated.

> That makes sense to me. I should have reported #1007002 earlier

No offence meant.

> (or, ideally, a Lintian co-maintainer should have pointed out the
> problems with a major tag format transition before it got that far),

That's more a thing. Actually I already thought if we should setup a
similar rule for Lintian tag syntaxes as we did for using epoch in
package versions, maybe just not as stringent. I'm though not sure
where such a rule should be placed. The Debian Policy seems the wrong
place. So that rule should be probably documented inside Lintian
itself or so.

> which would have made pausing or reverting the transition
> lower-cost.

Ack.

> Thank you for picking up this package! It's an important QA tool and
> I'm glad someone is looking after it again.

Should have noticed the resignation of Felix and Chris (or looked for
such a thing after noticing that there were no lintian uploads for a
while) earlier, too. Probably would have been less (or at least more
distributed) work to get it back in shape as the remainder of Debian
Unstable didn't stand still while Lintian did.

Especially I found one case where the amount of lines replacing the
#DEBHELPER# token caused test suite failures after a debhelper update
seem to have added some lines. Took a few hours to understand what
went wrong and why. (Granted, because many things I knew about
Lintian's test suite had changed since I last used it, I first had to
relearn how to use the current setup and this took probably some of
that time as well.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#1007002: lintian: transition to "pointed hints" has invalidated many overrides

2022-06-13 Thread Simon McVittie
Control: unblock 1006348 by -1

On Mon, 13 Jun 2022 at 05:15:19 +0200, Axel Beckert wrote:
> And #1007002 is only (!) about design decision to change nearly all
> tag formats involving file paths and line numbers. It has nothing to
> do with the other two real bugs and I have no idea why they have been
> merged.

I agree with your reasoning for unmerging, and I don't understand why
they were merged either.

#1007002 was marked as blocking #1006348 "lintian: Tag
improbable-bug-number-in-closes condition considers 7-digit bug numbers
improbable", but I think that was a side-effect of the merge and I don't
consider #1007002 to be RC or a blocker for #1006348, so I'm removing
that metadata.

> Since at least I will not revert such huge changes, I'll tag #1007002
> as "wontfix" for now and downgrade it to its original severity.
> 
> We can continue working on that bug report if we find someone who
> either will work on reverting all the related work (although I think,
> it's both, too late and also probably way too much work given all the
> other recent changes) or, probably much better, provide either a
> migration script or some code which also accepts the old override
> formats. In that case, I'd remove the "wontfix" again. (Sorry, Simon,
> I generally agree with #1007002, but we currently have way more severe
> issues with Lintian than #1007002. Hence I also didn't remove the
> confirmed tag.)

That makes sense to me. I should have reported #1007002 earlier (or,
ideally, a Lintian co-maintainer should have pointed out the problems with
a major tag format transition before it got that far), which would have
made pausing or reverting the transition lower-cost.

Getting a new Lintian release into testing and backports would at least
mitigate #1007002 by making sure that maintainers can write one tag format
that is equally valid for stable-backports Lintian, testing Lintian,
unstable Lintian and lintian.debian.org.

Thank you for picking up this package! It's an important QA tool and
I'm glad someone is looking after it again.

smcv



Bug#1007002: lintian: transition to "pointed hints" has invalidated many overrides

2022-03-10 Thread Simon McVittie
Package: lintian
Version: 2.114.0
Severity: important

There seems to be an ongoing transition in Lintian, in which hints that
report a filename or line in an ad-hoc way are being converted to "pointed
hints" that use a new format with the filename in square brackets.

One of the design decisions that keeps Lintian's value high as a
QA tool is that all of its hints (formerly known as tags) can be
overridden if the maintainer has assessed the hint and determined that
it is a false-positive or otherwise inapplicable to this particular
package. Unfortunately, changing a hint to a pointed hint invalidates
most overrides for that hint (unless they use a very broad wildcard match,
which seems like a bad idea since it could hide unrelated instances of the
hint that genuinely indicate a problem). I can see why it is considered
valuable to have a consistent format for all hints, but mass-invalidating
existing overrides seems like a high price to pay for that.

This is particularly frustrating when the overrides that would be required
to silence a hint on lintian.debian.org and the overrides that would
be required to silence a hint with the released version of Lintian are
mutually incompatible. https://lintian.debian.org/tags/mismatched-override
currently reports 15K mismatched overrides among 3K source packages,
which seems like a lot.

It would be useful if Lintian could treat previously-valid overrides as
still being a valid way to override the new form of a tag, particularly
in the common case where "foo usr/share/bar" has been replaced by
"foo [usr/share/bar]".

smcv