Hi Chris, On Wed, Mar 11, 2020 at 10:58 AM Chris Lamb <la...@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