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.

https://review.openstack.org/#/c/192327/


> 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

Reply via email to