Bug#935706: lintian: Make tag certainty a programmatic assessment
Hi Chris,
On Wed, Mar 11, 2020 at 10:58 AM Chris Lamb <lamby@debian.org> wrote:
>
> it appears to
> simply encode the currently unhelpful distinction between "wild-guess",
> "possible" and "certain" in a new and relatively unfamiliar way with
> a slightly ambiguous name.
I think this is a case of miscommunication. The new field,
provisionally called Visibility, can have the values "error",
"warning", "info", and "pedantic". They relate directly to the alert
level, or phrased with less presumption, to the visibility of the
diagnosis.
Any references to certainty or its values, "wild-guess", "possible"
and "certain", are gone. The table you quote is being removed.
> As it still has a concept of how confident the Lintian maintainers
> are, it will still be subject to the same "criticism" (as you call it)
> and thus continue the unproductive and demotivating levels of
> antagonism in otherwise legitimate bug reports that I am increasingly
> seeing.
Some old values for certainly are retained as text for research
purposes. They have no functionality and will not show on the website.
> My point all along is not that the concept of "certainty" has
> zero value, but rather that it has a negative one. ie. it is a cost
> and we should remove it.
My merge request does exactly that. The concept of certainty is gone.
There is no other way to do it. The merge request should be
uncontroversial, except perhaps for the name of the new field.
> As a minor point, I additionally would see no benefit in it being
> customisable between/for teams and believe this would just be cause
> for confusion when we attempt to reproduce & fix problems for our
> users.
This should really be discussed when it comes up, but for the record:
the customization will relate to the alert level. Why, for example,
should the golang team see 'package-has-long-file-name' about Joilet
file names as a warning for their 'library' packages when those are
unlikely to appear on a live CD?
The method of detection is not customized. Everything will be
reproducible unless suppressed, just like profiles work now.
> Let us focus on making Lintian simpler & fun to maintain and
> use instead.
That seems like an odd thing to write. Is my commit
https://salsa.debian.org/lintian/lintian/-/commits/92f2f155fb27abfb27523cab5df739bda3ebb552
not a step in that direction?
Kind regards
Felix Lechner
Reply to: