Re: "Lintian ratcheting" approach
On 2013-02-27 03:14, Hideki Yamane wrote:
> Hi,
>
> Thanks for your comment, Niels.
>
> On Tue, 19 Feb 2013 15:30:04 +0100
> Niels Thykier <niels@thykier.net> wrote:
>> However, I fear this idea will make people more frustrated with
>> Lintian and simply attempt to bypass the "ratchet" (or throw us a fit).
>> Not too long ago, the FTP-masters fixed a bug in their auto-reject
>> code and people were not pleased that their package was suddenly
>> rejected for "no apparent reason"[1]. So for me, that rules out the
>> server side option.
>>
>> I have a feeling that the client-side approach will have a similar
>> effect for these maintainers (assuming opt-out semantics).
>
> I understand you fear this may make people more frustrated then ignore
> lintian itself.
>
> But, wait - Why they may ignore Lintian?
>
> Because they don't believe it is necessary task for them, IMO.
> So, not "It's a new rule, obey this" approach but explaining
> "Why we should do that" for Consensus building is important to
> apply this.
>
> - It's a one of the challenge to improve our package quality
Some people disagree with (e.g.) binary-without-manpage being a sign of
"poor quality".
I remember a debate between Hauke (jhr) and Holger (h01ger) at a
mini-DebConf in 2010 about whether Lintian warnings (i.e. "W" tags) were
a useful metric for "quality". I remember here that
"binary-without-manpage" was one of the tags that made "W" tags a bad
metric for quality.
While the exact argument are hazy to me, the point is - some people
think Lintian is just a noisy tool with nothing better to do than
"demanding busy work for little-to-no benefit". Writing manpages to
"GUI tools" is one of those cases.
> - Increasing lintian errors and warnings is "Bad Smell".
> This feature probably prevents your package to be worse than previous (we hope)
> You can find such "sign" with using this experimental feature.
If "you" disagree with the lintian tags itself (or their severity), the
only thing that "smells" would be Lintian. I suspect that people
respect "E" tags more than "W" tags, but still - see my argument above.
> - However, sometimes it would hit false-positive result since lintian
> is not perfect (you know). So if you find something wrong with it,
> please report it to BTS.
I know Lintian has false-positives, but I am not entirely convinced that
people "understand" that Lintian can have false-positives.
I have seen several occasions where people (particular in
{,#}d-mentors), where people conclude that they have all hardening flags
enabled. Despite that, they continue with "Lintian keeps telling me
giving me hardening-no-fortify-functions. What did I do wrong?"[1].
Obviously the "regulars" know by now that the tag is fairly unreliable
(and tbh, I have been considering to demote it).
But it is not the only tag - see the repeated bugs about how "Lintian
doesn't get that I am just mentioning GPL in d/copyright, but it is not
under that license, so I shouldn't reference
/usr/share/common-licenses/GPL".
> - We don't enable this feature by default at first, but plan to switch
> enable in the future (so report false-positive is important).
>
> etc.
>
>> But with
>> using opt-in semantics, there is no actual point in the ratchet[2].
>> On a related topic, consider reading Russ Allbery's mail at [3].
>
> In the end, it should be opt-out ratcheting but start it with opt-in
> is better (lintian opt-out is another issue).
>
>
>> So, for me, a prerequisite to doing the ratchet is that Lintian is not
>> (going to be) preceived as a "pain". Not only in correctness of results
>> (accuracy), but also in speed.
>
> Well, ratcheting approach is just compare previous result (that is in
> lintian.d.o) and current output. It doesn't make the situation worse.
>
I suppose it would be possible to show a "diff since last version" on
lintian.d.o. I don't think that would cause any issues (except finding
time|someone to code it).
~Niels
[1] Yes, there is also the opposite case where they think they are right
and it turns out that they forgot the CPPFLAGS... Still blhc does a far
better job than hardening-check for this.
Reply to: