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

[Rob Crittenden]

Petr Spacek wrote:
> 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.
>

We did this specifically to keep bad changes out of the tree. You're 
suggesting catching them after commit rather than before. We tried that, 
it didn't work out so well.

rob