I agree with Rob in terms of tooling and with Travis on rules.

Any linting tool is fine with me as long as it does not break the rules we currently have set in Horizon. I believe the rules right now are general enough, so switching to eslint might not be an issue, but its something to look into. And we are still early in the JSCS stages, so this is actually opportune timing. I don't have a strong opinion on which tool so as long as it gets the job done and does not stall work in Horizon for liberty.

-----Michael Krotscheck <krotsch...@gmail.com> wrote: -----
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
From: Michael Krotscheck <krotsch...@gmail.com>
Date: 06/16/2015 12:30PM
Subject: Re: [openstack-dev] [_javascript_] [horizon] [merlin] [refstack] _javascript_ Linting



On Tue, Jun 16, 2015 at 10:22 AM Tripp, Travis S <travis.tr...@hp.com> wrote:
I think agreeing on rules is the bigger problem here and I don’t think all
the projects should have to agree on rules.

I believe we agree there, mostly. I personally feel there is some benefit to setting some rules, likely published as an openstack linting plugin, which enforce things like "Do not use fuzzy versions in your package.json" and other things that make things unstable. That should be a very carefully reserved list of rules though.

I've created an eslint configuration file that includes every single rule, it's high level purpose, and a link to the details on it, and provided it in a patch against horizon. The intent is that it's a good starting point from which to activate and deactivate rules that make sense for horizon.

 
We’ve spent a good portion of liberty 1 getting the code base cleaned up to meet the already adopted horizon rules and it is still in progress.

As a side note, the non-voting horizon linting job for _javascript_ things is waiting for review here: https://review.openstack.org/#/c/188886/

My preference would be to see if we can use eslint to accomplish all of
our currently adopted horizon rules [3][4] AND to also add in the angular
specific plugin [1][2]. But we can’t do this at the expense of the entire
liberty release.

Again, I agree. The patch I've provided above sets up the horizon eslint build, and adds about... 10K additional style violations. Since neither of the builds pass, it's difficult to see the difference, yet either way you should probably tweak the rules to match horizon's personal preferences.

Michael
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to