On 09/10/2014 02:51 PM, Monty Taylor wrote:
On 09/10/2014 11:32 AM, Jeremy Stanley wrote:
On 2014-09-10 11:14:26 -0700 (-0700), Monty Taylor wrote: [...]
However, I am not a lawyer, and reasonable people disagree with my views.
I mostly agree with your views (which probably makes me unreasonable). My bigger concern is that we are unlikely to convince, say, Debian to reconsider their position on the non-freeness of the license nor on their desire to be able to rebuild OpenStack components they distribute, so in effect requiring JSHint for generating or running parts of Horizon effectively means we are sending the signal we no longer want Debian to carry Horizon.
I do not care if Debian re-runs our code style checks. I think as long as we don't run jshint inside of the unittest runs - but instead run it as a separate job like we do with pep8, then I think Debian legal's POV on this is irrelevant. I _do_ agree that if it were a part of actual build or test pipeline that we should avoid it for that reason.
In this case, though, I think the subject line/problem description is misleading. Digging deeper into the current state of Horizon it appears that JSHint is only a recommended tool for developers and one we also call in automated code style checks[1]. As long as it's not actually required to reproduce a usable version of Horizon from source and run it then I don't think there's likely to be any actual problem.
I think we should run it as part of horizon's pep8 job, because that's what we do around here. And I don't think that should prevent debian from doing anything.
[1] ...at least 'git grep -il jshint' only returns doc/source/ref/run_tests.rst, run_tests.sh and tox.ini
Agree. I can't see how this has any licensing implications as a style check. It's not being linked in any way with OpenStack code. -Sean -- Sean Dague http://dague.net