[Freeipa-devel] [PATCH 0050] Allow to skip lint when building FreeIPA.

[Petr Spacek]

On 4.6.2015 15:11, Rob Crittenden wrote:
> Alexander Bokovoy wrote:
>> On Thu, 04 Jun 2015, David Kupka wrote:
>>> On 06/04/2015 12:43 PM, Alexander Bokovoy wrote:
>>>> On Thu, 04 Jun 2015, David Kupka wrote:
>>>>>
>>>>> -- 
>>>>> David Kupka
>>>>
>>>>> From f68607e9a3db4cd8893c465d804615aac34afc29 Mon Sep 17 00:00:00 2001
>>>>> From: David Kupka <dkupka at redhat.com>
>>>>> Date: Thu, 4 Jun 2015 12:10:37 +0200
>>>>> Subject: [PATCH] Allow to skip lint when building FreeIPA.
>>>>>
>>>>> Target 'lint' does nothing when SKIP_LINT is set to anything else than
>>>>> "no".
>>>>> By default the variable is unset and lint is executed as always was.
>>>> Is there any reason to support this?
>>>>
>>>> I personally don't like to be able to skip lint as Python gives you too
>>>> many ways of shooting yourself.
>>>>
>>>
>>> On the other hand, running lint every time even when building
>>> unchanged master is waste of (a lot of) time. I really prefer running
>>> ./make-lint (or make lint) to check the code and 'make rpms' to build
>>> packages.
>>>
>>> Moreover, the default behavior stays the same, lint is always run.
>> So you can add a hook to use a git committish and check the change
>> between them so that only when there is indeed a change, you run lint.
>> And for cases when you are running off a tarball, simply disable lint --
>> automatically.
>>
>> What in reality will happen if we allow setting SKIP_LINT permanently in
>> the environment, we'd be less careful on the code checks. Sorry to be
>> harsh here but that is how it goes. If lint is costly to run, optimize
>> to run it only when it really is needed but not disable it voluntarily.
>>
> 
> +1
> 
> I totally agree that it is getting out of hand speed/resource-wise. I had more
> than one build fail due to OOM. But I don't think disabling it is the right
> way because, as Alexander said, once disabled always disabled.

Sorry, I do not agree. All automated build systems will not have the variable
defined so arbitrary pylint-detectable error will be *in the worst case*
(where no developer ever runs pylint) caught by:
- Jenkins builds (after each commit)
- Coverity build (every day)
- COPR (as needed)
- Koji (before packages for Fedora are built).

That sounds like a good resource trade-off, especially if we agree that
automated tests are necessary anyway because pylint cannot uncover semantical
errors.

-- 
Petr^2 Spacek