I can't say I'm too deeply versed in the code, but it's enough to make
me wonder if we want to go that direction and avoid the issues altogether?
It's the nature of python that methods and modules can be added in runtime
and pylint can't do full analysis. That's why the best use of it - limited
At first step we won't implement pylint as gate job, but will add it at
master to have a possibility to check code with pylint locally, if it is
needed.
No much sense in running it locally. It has too many false positives. The
best use - see new critical errors as a non-voting job.
Andrew.
On
My points are next:
1. Pylint check will be very useful for project, and will help to
avoid critical errors or mistakes in code.
2. At first step we won't implement pylint as gate job, but will add
it at master to have a possibility to check code with pylint locally,
if it is needed.
3. In
Igor,
Personally this idea looks really nice to me, as this will help to avoid
strange code being merged and not found via reviewing process.
Cheers,
Dina
On Fri, Oct 3, 2014 at 12:40 PM, Igor Degtiarov idegtia...@mirantis.com
wrote:
Hi folks!
I try too guess do we need in ceilometer
From: Dina Belova [mailto:dbel...@mirantis.com]
On Friday, October 03, 2014 2:53 AM
Igor,
Personally this idea looks really nice to me, as this will help to avoid
strange code being merged and not found via reviewing process.
Cheers,
Dina
On Fri, Oct 3, 2014 at 12:40 PM, Igor
On Oct 3, 2014, at 1:09 PM, Neal, Phil phil.n...@hp.com wrote:
From: Dina Belova [mailto:dbel...@mirantis.com]
On Friday, October 03, 2014 2:53 AM
Igor,
Personally this idea looks really nice to me, as this will help to avoid
strange code being merged and not found via reviewing
You can turn off lots of the refactor recommendation checks. I've been
running pylint across neutron and it's uncovered half a dozen legitimate
bugs so far - and that's with many tests still disabled.
I agree that the defaults are too noisy, but its about the only tool that
does linting across
