Please pull u-boot-dm (take 3)

[Simon Glass]

Hi Tom,

On Thu, 10 Feb 2022 at 13:40, Tom Rini <trini at 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 at 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