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 <norb...@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