<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 16, 2014 at 2:54 PM, Angus Salkeld <span dir="ltr"><<a href="mailto:angus.salkeld@rackspace.com" target="_blank">angus.salkeld@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div><div><div>On 17/06/14 02:46, Ben Nemec wrote:<br>
> On 06/16/2014 08:37 AM, Thierry Carrez wrote:<br>
>> Sean Dague wrote:<br>
>>> Hacking 0.9 series was released pretty late for Juno. The entire<br>
>>> check queue was flooded this morning with requirements proposals<br>
>>> failing pep8 because of it (so at 6am EST we were waiting 1.5 hrs<br>
>>> for a check node).<br>
>>><br>
>>> The previous soft policy with pep8 updates was that we set a<br>
>>> pep8 version basically release week, and changes stopped being<br>
>>> done for style after first milestone.<br>
>>><br>
>>> I think in the spirit of that we should revert the hacking<br>
>>> requirements update back to the 0.8 series for Juno. We're past<br>
>>> milestone 1, so shouldn't be working on style only fixes at this<br>
>>> point.<br>
>>><br>
>>> Proposed review here - <a href="https://review.openstack.org/#/c/100231/" target="_blank">https://review.openstack.org/#/c/100231/</a><br>
>>><br>
>>> I also think in future hacking major releases need to happen<br>
>>> within one week of release, or not at all for that series.<br>
><br>
>> We may also have reached a size where changing style rules is just<br>
>> too costly, whatever the moment in the cycle. I think it's good<br>
>> that we have rules to enforce a minimum of common style, but the<br>
>> added value of those extra rules is limited, while their impact on<br>
>> the common gate grows as we add more projects.<br>
><br>
> A few thoughts:<br>
><br>
> 1) I disagree with the proposition that hacking updates can only<br>
> happen in the first week after release. I get that there needs to be<br>
> a cutoff, but I don't think one week is reasonable. Even if we<br>
> release in the first week, you're still going to be dealing with<br>
> hacking updates for the rest of the cycle as projects adopt the new<br>
> rules at their leisure. I don't like retroactively applying milestone<br>
> 1 as a cutoff either, although I could see making that the policy<br>
> going forward.<br>
<br>
</div></div>Can't we move to a mode of enabling rules instead of ignoring them?<br>
If we did this in tox.ini then it wouldn't matter when you release<br>
hacking.<br>
<br>
[hacking]<br>
errors = H306,...<br>
ignore = H101<br>
<br>
So if you upgraded hacking you would not get the new checks generating<br>
errors, but only warnings.<br></blockquote><div><br></div><div>This is out side the scope of hacking in and in the domain of the flake8 project, although we can easily contribute upstream to it. </div><div><br></div><div>
As for warnings, I assume you mean we log the issue but don't gate on it, I don't think anyone would pay attention to them, so not sure what the value is.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I guess the list of rules to error on would get big, but maybe we could have<br>
some short cuts (H3*,H2*)?<br>
<br>
At least the projects are a bit more in control of what rule they add. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- -Angus<br>
<div><div><br>
><br>
> 2) Given that most of the changes involved in fixing the new failures<br>
> are trivial, I think we should encourage combining the fixes into one<br>
> commit. We _really_ don't need separate commits to fix H305 and H307.<br>
> This doesn't help much with the reviewer load, but it should reduce<br>
> the gate load somewhat. It violates the one change-one commit rule,<br>
> but "A foolish consistency..."<br>
><br>
> 3) We should start requiring specs for all new hacking rules to make<br>
> sure we have consensus (I think oslo-specs is the place for this). 2<br>
> +2's doesn't really accomplish that. We also may need to raise the<br>
> bar for inclusion of new rules - while I agree with all of the new<br>
> ones added in hacking .9, I wonder if some of them are really necessary.<br>
><br>
> 4) I don't think we're at a point where we should freeze hacking<br>
> completely, however. The import grouping and long line wrapping<br>
> checks in particular are things that reviewers have to enforce today,<br>
> and that has a significant, if less well-defined, cost too. If we're<br>
> really going to say those rules can't be enforced by hacking then we<br>
> need to remove them from our hacking guidelines and start the long<br>
> process of educating reviewers to stop requiring them. I'd rather<br>
> just deal with the pain of adding them to hacking one time and never<br>
> have to think about them again. I'm less convinced the other two that<br>
> were added in .9 are necessary, but in any case these are discussions<br>
> that should happen in spec reviews going forward.<br>
><br>
> 5) We may want to come up with some way to globally disable pep8<br>
> checks we don't want to enforce, since we don't have any control over<br>
> that but probably don't want to just stop updating pep8. That could<br>
> make the pain of these updates much less.<br>
><br>
> I could probably come up with a few more, but this is already too<br>
> wall-of-texty for my tastes. :-)<br>
><br>
</div></div>> -Ben<br>
<div>><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br>
</div><div>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
</div>iQEcBAEBAgAGBQJTn2eqAAoJEFrDYBLxZjWo9dkIAJ55WTdVZgIHEFJGp+7Px8jC<br>
FxsBzRvDKeDTN6ONXUtE82G10ru6UR0HNndfhgbdEVQSazdcavbd/Q0AG+tmDyaE<br>
7PBUpJ3bVIQVpJQ9tz/Xo4dqvsZhsOZBo28iLJyShU+VYy05I16WCGpsS0NUlD95<br>
ND78vjwUCNnjbzkOgBjt6V0QsuWpEZynIR6PfRkUJaaT+gFtrhAG7n4aQmgYnJri<br>
9huTnEjyyg9KldlinxLxVP9nk2uVoKD7sfDAvREAjstFeRK4tVcdspB6xxPkfTKA<br>
RDAG1tGT0yvD3VtgqajFlJvImUyV7YN3/zXyXxKeb0301ouWpFeyiSZ1jqsK6Nc=<br>
=/Tmf<br>
<div><div>-----END PGP SIGNATURE-----<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</div></div></blockquote></div><br></div></div>