Open Stack

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