<div dir="ltr"><div>you can split H306 to several patches since it contains  so much files. <br><br></div>optional: It would be really nice if you can fix the unused import problem (if exist) in the same time, this seems can be checked via IDE<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 22, 2014 at 7:23 PM, Pavlo Shchelokovskyy <span dir="ltr"><<a href="mailto:pshchelokovskyy@mirantis.com" target="_blank">pshchelokovskyy@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div>we have an approved blueprint that concerns reducing number of ignored PEP8 and openstack/hacking style checks for heat (<a href="https://blueprints.launchpad.net/heat/+spec/reduce-flake8-ignored-rules" target="_blank">https://blueprints.launchpad.net/heat/+spec/reduce-flake8-ignored-rules</a>). I've been already warned that enabling some of these rules will be quite controversial, and personally I do not like some of these rules myself either. In order to understand what is the opinion of the community, I would like to ask you to leave a comment on the blueprint page about what do you think about enabling these checks.</div>


<div><br></div><div>The style rules being currently ignored are:</div><div>F841 local variable 'json_template' is assigned to but never used</div><div>H201 no 'except:' at least use 'except Exception:' (this actually checks for bare 'except:' lines, so 'except BaseException:' will pass too)</div>


<div>H302 do not import objects, only modules (this I don't like myself as it can clutter the code beyond reasonable limit)</div><div>H306 imports not in alphabetical order</div><div>H404 multi line docstring should start with a summary</div>


<div><br></div><div>Another question I have is how to proceed with such changes. I've already implemented H306 (order of imports) and am being now puzzled with how to propose such change to Gerrit. This change naturally touches many files (163 so far) and as such is clearly not suited for review in one piece. The only solution I currently can think of is to split it in 4-5-6 patches without actually changing tox.ini, and after all of them are merged, issue a final patch that updates tox.ini and any files breaking the rule that were introduced in between. But there is still a question on how Jenkins works with verify and merge jobs. Can it happen that we end up with code in master that does not pass pep8 check? Or there will be a 'race condition' between my final patch and any other that breaks the style rules? I would really appreciate any thoughts and comments about this.</div>


<div><br></div><div>Best regards,</div><div>Pavlo Shchelokovskyy.</div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div>blog: <a href="http://zqfan.github.com" target="_blank">zqfan.github.com</a><br></div>git: <a href="http://github.com/zqfan" target="_blank">github.com/zqfan</a><br>
</div>
</div>