Re: About lintian
Hi Norbert,
First of all, please accept my apologies for responding late. I
subscribe to d-d but filter lists for later perusal. Thanks to Lucas
Nussbaum for pointing me here!
Due to the number of messages already posted in this thread, I will
respond—with the best of ability—to each message separately.
Thank you also for being cautious about people's emotions. I endure a
fair amount of abuse for working on Lintian and am likewise reluctant
to discuss it in such a broad forum, but here we are.
David Bremner once said that people should remember Lintian isn't
their boss. (David, please correct me if I fumbled that.) My goal is
for Lintian to provide friendly packaging advice for the benefit of
maintainers. Nothing more and nothing less.
On Sun, Jan 17, 2021 at 5:02 AM Norbert Preining <norbert@preining.info> wrote:
>
> In the past year, many changes in lintian tag names occurred, along with some
> tag removals.
While we often change tag names (or combine tags etc.), the majority
of the renames people talk about seems to stem from two bug reports by
third parties asking that we make tag names more consistent (bug
numbers are available, if needed). As I remember, I studied the
related checks—some of which were quite dense or antique—for ten days
before settling on new names. Alas, that effort earned mostly anger
and, in one case, even disapproval from a bug filer.
> While it seems quite normal for lintian as a tool to evolve a
> lot, with the upcoming freeze, do you see a reasonable time frame during which
> these kind of changes could be postponed to help people having lintian-clean
> packages remain lintian-clean till after release?
I am totally open to suggestions, although I think that being
"Lintian-clean" is overrated. My goal is not to point out faults like
a heavenly prosecutor but to help people avoid common problems. Tag
names do not make a difference in that regard.
I am also not sure that a tag rename by itself could ever trigger new
tags, i.e taint a package that was previously "Lintian-clean".
> On the infrastructure side, you mentioned on #debian-qa that in your
> opinion, lintian is best run in a CI pipeline instead of on the
> lintian.d.o service. While this is certainly true, do you plan to keep
> the functionality on your rework of lintian.d.o?
Yes, in fact the goal for the new lintian.d.o is much broader (and
hopefully not too ambitious). The website should ultimately allow
detailed research into which packages trigger particular tags
(including various filtering functions and automatic notifications).
The website should also offer ways to flag ineffective tags, i.e.
those with a high proportion of false positives based on the
prevalence of overrides.
With tongue in cheek, I may one day add a voting system for the
funniest, or perhaps the most bogus, override comment.
People should also be able to flag false positives with a few clicks
(perhaps triggering a bug report) or generate overrides for their
packages for download.
My remark about Salsa CI probably applied more to maintainers of
single packages, and less to people concerned with quality assurance
of large package families such as yourself.
In any event, the Lintian job on Salsa broke when the (privileged)
runners were upgraded to Debian 10. Something in Lintian triggers
apparmor. Despite the prominence of the failures I have been reluctant
to explore them. I am not sure that the Salsa and the Salsa CI teams,
at whose juncture the apparmor process resides, have the best
relationship. On top of that, my principal collaborator on Salsa CI,
Iñaki Malerba, is busy with a new job.
> As part of this rework and the ongoing development, you said you have plans
> to set up a test version of the Lintian web application on non-Debian
> infrastructure.
I have a Node.js version that almost replaces the old lintian.d.o. My
primary challenge is the amount of data Lintian now generates.
Uploading results to Postgres via bulk JSON takes several hours.
The domain lintian.debian.net resolves to a non-Debian server with my
experimental version, but it's a work-in-progress and the data is not
current. I could probably finish it in a week if I had the time.
> The
> intention of this mail is to understand the current Lintian's maintainers POV
> on what Lintian is and should be
I do not think I answered that question except for my favorite
tagline: "Lintian provides friendly packaging advice for the benefit
of maintainers."
Thank you for your interest in Lintian!
Kind regards,
Felix Lechner
Reply to: