On Thu, Feb 10, 2022 at 02:01:21PM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 10 Feb 2022 at 13:40, Tom Rini trini@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 trini@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?
Yeah, OK. I'd like to focus on fixing the serious violations, make that a CI check and let any other cleanups be up to the script authors as time permits, rather than within CI. Maybe we keep pylint.base, but update it per release and it's more informative than basis for pass/fail on changes.
Regards, Simon