Hi Tom, On Thu, 10 Feb 2022 at 13:40, Tom Rini <tr...@konsulko.com> wrote: > > On Thu, Feb 10, 2022 at 01:23:36PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 10 Feb 2022 at 13:08, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Wed, Feb 09, 2022 at 12:52:02PM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > This just drops off the final patch of 'take 2' since that is being > > > > reworked. > > > > > > > > > > > > running here: > > > > > > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/10936 > > > > > > > > > > > > The following changes since commit > > > > 859703251251d9567f29ab10c0a29f98eb0aff5c: > > > > > > > > Merge branch '2022-02-08-Kconfig-updates' (2022-02-09 09:29:07 -0500) > > > > > > > > are available in the Git repository at: > > > > > > > > git://git.denx.de/u-boot-dm.git tags/dm-pull-8feb22-take3 > > > > > > > > for you to fetch changes up to f3078d4ea707931c2307a623ecf6e4d215b413d5: > > > > > > > > binman: Convert FIT entry type to a subclass of Section entry type > > > > (2022-02-09 12:30:13 -0700) > > > > > > > > > > So first, applied to u-boot/master. But I still had to re-generate > > > scripts/pylint.base, and some numbers went down, but the code is > > > cleaner. Can we just make pylint fail when there's serious errors with > > > the code perhaps? > > > > Do you mean fail when the numbers go down? > > No, it fails today when the numbers go down, like this PR did. Or would > have if I didn't just ignore it and accept the lower number because the > code was cleaned up. I mean is there some way to get pylint to say > "this code has serious violations" and non-zero exit rather than just > assign the code a numeric grade?
pylint is one of the world's slowest programs. We run in parallel on each file to keep the run time bearable. The return code for individual pylint processes is generally non-zero, unless we happen to get a score of 10. We could use --fail-under but that seems to fail often enough even if the score is exactly equal to the value provided (i.e. we need to subtract 0.01). We could add pylint checking to gitlab and 'make check' since it does at least provide a list of files which have got worse. As to 'serious violations', there are already a lot. There is a flag to only consider certain classes of violations, but for now we cannot turn that on. Perhaps that should be a first step? Regards, Simon
