I would love to help to make Lintian faster, but unfortunately I don't know any Perl, so touching an advanced package like this will take a lot of time (learn Perl -> get somewhat proficient -> start hacking Lintian). I might be able to profile it though to understand its pain points, which I'll try to give a go.
Cheers, H. On 9.05.2024 ÖS 11:57, Soren Stoutner wrote:
I would like to respectfully disagree will some of the opinions expressed in this email.First, I should say that I am painfully aware of how long it takes to run lintian on large packages. When working on qtwebengine-opensource- src it takes my system (Ryzen 7 5700G) about 2 hours to build the package and about half an hour to run lintian against it. I would be completely in favor of any efforts that could be made in the direction of making lintian more efficient, either within lintian itself or in other packages that replicate some or all of lintain’s functionality in more efficient ways.However, I personally find lintian to be one of the most helpful tools in Debian packaging. When going through the application process I found lintian to be a very useful tool in helping me learn how to produce packages that conform to Debian’s standards. The integration of lintian into mentors.debian.net was very helpful to me when I first started submitting packages to Debian, and it is still helpful to me when reviewing other people’s packages that have been submitted to mentors.debian.net.As I type this email I am building an update to qtwebengine-opensource- src. So far, lintian has caught two problems with this release that I would have otherwise missed. I admit that I am fairly new as a Debian Developer, and perhaps as I gain greater experience I would get to the point where lintian never catches things I miss. But I don’t personally expect that to ever happen, because there are too many corner cases or opportunities for typos that computers are much better at catching than humans.I do understand that lintian is in need of a lot of work. I personally have an open MR against the package that fixes a check that is wrong more often than it is right (with both false positives and false negatives). The fix is relatively simple and makes the check 100% accurate as far as I can tell. However, after over a year, it has yet to be reviewed.https://salsa.debian.org/lintian/lintian/-/merge_requests/461 <https:// salsa.debian.org/lintian/lintian/-/merge_requests/461>I must admit that I have been sorely tempted to get involved with maintaining lintian because I feel it is so important. So far, I have resisted that temptation because I am already involved in a decade-long effort to clean up Qt WebEngine in Debian and get it to the point where it has proper security support. I haven’t wanted to spread myself too thin and end up accomplishing nothing because I tried to do too much. But if lintian’s need increases or if my existing commitments decrease I would be happy to find myself involved with lintian maintenance.Soren On Thursday, May 9, 2024 12:27:49 PM MST Andreas Tille wrote: > 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. -- Soren Stoutner soren@debian.org
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature