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.