Re: Any volunteers for lintian co-maintenance?
Hi,
this mail is a private response from Niels to my mail to the Debian Perl
team where I explicitly asked for people helping out with lintian. So
far the answer from Niels is the only response. Since he gave explicit
permission to quote him in public I'm doing so hereby. Niels assumed
that his answer "will not help my case" - but well, I do not think that
hiding problems will help anybody else.
At Tue, May 07, 2024 at 15:59:21 +0200 Andreas Tille wrote
> Hi Perl folks,
> ...
> --> see full mail at https://lists.debian.org/debian-perl/2024/05/msg00000.html
>
[ From here I simply quote Niels unchanged - I'll comment probably tomorrow in detail ]
Hi Andreas
You are welcome to quote me in public, though I feel it will not help your
cause. This reply is in private to you, so you can choose whether you want
to quote me.
I agree with the sentiment that important Debian tools would ideally be
co-maintained. However, in the passing years, I have started to feel a
disconnect with lintian, its direction and what I would like to see. I no
longer use lintian and I am fundamentally not interested in picking up
lintian anymore - neither as a user nor as a contributor. I have even
uninstalled it from my machines. For now, I still "allow" it in my salsa-ci
pipeline but my patience with it is thin.
For me, lintian fails in all roles it has. It is not a good tool for newbies
to get help, since it can only test build artifacts. As an example, your
feedback look is a full package build followed by unpacking the package just
so lintian can tell you have a typo on line 4. That is a massive waste of
resources - notably developer time and mental bandwidth.
It also fails as an archive QA tool in my view since the FTP masters have
been unwilling to upgrade to any recent version of lintian. I think FTP
master's argument lies with the very poor performance in certain corner
cases that adversely affects larger packages (like linux). As a consequence,
people now get auto-rejects when uploading because lintian on the FTP master
server does not produce the same output as current lintian in stable or
newer.
For the record, I support the FTP masters here since the performance was
quite horrible at some point (might be fixed, might not be) and that would
just block benign uploads. In fact, I would go so far as to say that the FTP
masters should remove lintian from their upload checks (partly because of
this, partly because only source packages are reliably checked which neuters
the original point of adding lintian to the upload queue).
The latter half (archive-wide qa + performance + trust) might be fixable
with a dedicated effort and then a lot of lobbying to restore's people trust
in lintian. But that is a lot of work, and it will not solve the former
(feedback cycles). The former requires a completely different mindset and
scope for the tooling.
To that end, I have decided to put my effort into `debputy` where I recently
added support for linting *with* quickfixes, reformatting and editor support
(the latter via LSP). I think that a much better approach to half of the
issues that lintian emits and helps both newcomers and long term
contributors to be much more productive. Especially for the editor support
related parts, where people get instant feedback both on issues and the fix,
automatic reformatting on save and completion suggestions. None of which
lintian or wrap-and-sort are capable of.
If I am successful, then lintian can specialize its efforts into issues only
visible in packaged artifacts and thereby reduce it scope a bit. In that
sense, my work might be a (minor) help to the Lintian team on the assumption
they are willing to specialize more. But even if I am not successful with
`debputy`, I cannot imagine I would consider returning to lintian. It does
not scratch my itch and years of issues (some of which are still unfixed)
have made me not want to have anything to do with the tool.
Best of luck to Axel and anyone joining him to stop the bleeding. I do hope
they are successful, since lintian still have valuable features for Debian
as a whole that can be salvaged. But I am not going to be the "hero" that
salvages that mess. If I am going to do heroics in this area, then it will
be related to `debputy` with the aim to enable us to spend less mental
bandwidth on daily packaging work.
Best regards,
Niels
PS: In my view, the bleeding of lintian's quality started long before Axel
joined the lintian maintenance team and I do not fault Axel for being unable
to stop the bleeding. In my view, only a hero could have "managed" that at
the expense of their mental health.
Reply to: