On Mon, 18 May 2015 17:35:07 +0200, Niels Thykier wrote: > On 2015-05-18 17:07, gregor herrmann wrote: > > On Sat, 16 May 2015 19:30:40 +0200, Axel Beckert wrote: > >> gregor herrmann wrote: > >>> On Fri, 15 May 2015 21:32:29 +0200, Axel Beckert wrote: > >>>> * library-package-name-for-application > >>>> * application-in-library-section > >> With regards to library-package-name-for-application and > >> application-in-library-section, I've set "Certainty: possible" > > I'd rather rate it as "wild guess" :) > >> But yes, those tests will generate false positives and I currently > >> have no idea how to reduce the amount of false positives noticably. > > Me neither, sorry. > Based on this remark, I suspect "wild-guess" is indeed better. Ok. > Do you think that more data be helpful here? I.e. if we collected a > full run worth of data from lintian.d.o, do you think we could increase > the reliability of the tag? I'll let Axel answer this question; personally I'm a bit skeptical that more data alone will show anything new; I guess we have to think about the logic a bit more (currently it basically checks for anything in $PATH). > I must admit that I am a bit concerned about adding (more) wild-guess > tags. They can quickly become a drain on resources because they can > trivially receive a lot of bugs to fix false-positive. *nod* > >>> Check: debhelper (perl-specific) > >>> Tag: arch-any-package-needs-newer-debhelper (*) > >>> Tag: module-build-tiny-needs-newer-debhelper > >> I presume the same issue holds for these. > > Well, packages with Module::Build::Tiny would just explode instead of > > build without the fix in debhelper 9.20140227. Currently this is no > > issue as long as a debhelper version >= stable is used but until a > > few weeks ago the then stable version was not enough and the check > > helpful. - Since this still affects potential backports to oldstable > > I would personally keep it. > While it is certainly /not/ a blocker, the concern from my PoV is that > the expected life time of these tags are now less than a year and not > relevant to unstable/testing. > Unless the merge (plus release) happens "really soon(tm)", we might be > a in a position where we spend time moving the tag only to find it > obsolete by the time it is deployed. Ok, I see this point about obsolescence. > >>> Check: usr-lib-perl5 > >>> Tag: usr-lib-perl5-mentioned > >> Ok. Please: > >> * Chose a more descriptive tag name. Maybe: > >> "mentions-deprecated-usr-lib-perl5-dir" > > Hm, deprecated is not exactly true in my understanding, is not used > > anymore. > If it is not used anymore, then perhaps > "mentions-obsolete-usr-lib-perl5" or maybe > "references-unused-usr-lib-perl5" ? I guess 'obsolete' was the word I was looking for in vain :) 'references' might be a bit more precise then 'mentions', so, in best bikeshedding mode, I'd suggest 'references-obsolete-...' :) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Opus: Flying High
Attachment:
signature.asc
Description: Digital Signature