On 4.6.2015 16:18, Alexander Bokovoy wrote:
> On Thu, 04 Jun 2015, 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 <dku...@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)
> Let them run make-lint
>> - Coverity build (every day)
>> - COPR (as needed)
>> - Koji (before packages for Fedora are built).
> None of the above run off the git repo directly and none of the above
> run 'make rpms'.
>> That sounds like a good resource trade-off, especially if we agree that
>> automated tests are necessary anyway because pylint cannot uncover semantical
>> errors.
> Sorry, this all looks fine until you actually look at the flow in
> Makefile.
> lint target is called by
> rpms: rpmroot rpmdistdir version-update lint tarballs
> client-rpms: rpmroot rpmdistdir version-update lint tarballs
> srpms: rpmroot rpmdistdir version-update lint tarballs
> None of these targets is called when running 'make all' or 'make client'

It is surely better to let developers building RPMs 10x a day to just replace
make-lint with an empty file and *then* let them forgot about this change.

This discussion costed me too much time so I'm giving up. Have a nice day!

Petr^2 Spacek

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to