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)
- 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
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
