Re: "Lintian ratcheting" approach
On 2013-02-19 07:32, Hideki Yamane wrote:
> Hi,
>
> I've hit upon an idea, named "Lintian ratcheting" approach to improve
> Debian packages.
> see https://docs.google.com/document/d/1VZWGzccH_v9kbsjACRMhr0fgUllKqb1mmfWi7LkfE8A/edit?usp=sharing
>
> Any comments are welcome.
>
>
Hi,
Interesting idea and I truly appreciate the interest in getting a
Lintian clean archive. The server side option reminds me of the
FTP-master auto-rejects.
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). 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].
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. Lintian does fairly well on the
"average" cases, but I fear we fail on the "rest" of the cases[4].
It would be possible to work around the accuracy problem by only
considering a known accurate subset of our tags (like done with the
ftp-master auto-rejects).
~Niels
[1] Nevermind the fact that a -F would have told them this should have
happened for ages. Also, most of the frustration I have seen so far has
been on IRC, so I cannot link to it.
[2] People that opt-in are probably the same people that will go over
and above in fixing their Lintian warnings (and won't need the option to
do it).
[3] https://lists.debian.org/debian-lint-maint/2012/01/msg00034.html
[4] For accuracy, there are plenty of false-positives around that (some
not reported). For speed, consider packages like linux - all its
binaries (from a single arch) and its source in a single run takes a
substational amount of time (say hi to "death-by-1000-needles" man(1) on
the linux-manual package).
Reply to: