<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 16, 2014 at 2:56 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Jun 16, 2014 at 2:23 PM, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>> wrote:<br>


><br>
> On Jun 16, 2014 9:44 AM, "Ben Nemec" <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>> wrote:<br>
>><br>
>> -----BEGIN PGP SIGNED MESSAGE-----<br>
>> Hash: SHA1<br>
>><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>
> This is a general issue with global requirements, the number of jobs we run<br>
> and the number of available nodes. Let's solve the general case.<br>
><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>
><br>
> ++<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>
><br>
> ++<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>
><br>
> I would rather just have more folks review hacking patches then add a specs<br>
> repo. A specs repo is overkill, IMHO, hacking doesn't have that many patches<br>
> per cycle. In general when adding a rule to hacking it has to already be in<br>
> HACKING.rst and/or needs a ML post.<br>
<br>
</div></div>You wouldn't need a new repo. Hacking is part of the Oslo program, so<br>
you would use oslo-specs just like the other Oslo projects.<br>
<br>
The process you describe is what we've done historically, but as we<br>
standardize on specs repos we will want to eventually reconsider it.<br>
If the point of posting to the mailing list is to encourage<br>
discussion, then it seems like that step could be replaced with a<br>
spec.<br></blockquote><div><br></div><div>Perhaps, I still am not sure how that really helps.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Doug<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
>> - -Ben<br>
>> -----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>
>> iQEcBAEBAgAGBQJTnx7wAAoJEDehGd0Fy7uqoYAH/0KmxmR873Qn2Kti7LIEUNp4<br>
>> 1FJaBOX09ItxkkvyNRpcsIQu4fWycm60CckSOLfB7rgxgIjgsVkiZ9puE6oCmj2o<br>
>> Lhe5DhjYA2ROu9h8i0vmzYDnAKeu/WuRGtgyLSElUXeuiLpSrBcEA/03GpkCGiAP<br>
>> 1muAkVgv2oxDDwsaLwL7MmFrlZ1MPTP97lAfsfHbwbsOM5YMuPrRz9PirgHPBtTV<br>
>> 59UyofCGEBTtJKmJRLzRDZyDwTux5xrrc/cefer5GFLQH0ZbxOU1HHFESyc5wFVJ<br>
>> tI/3nPlbFpqCUtgmnQc8k3lX3d2H1Qr9UfCvYlJFTN1TmPmHmK378ioi81HoAVo=<br>
>> =tqtf<br>
>> -----END PGP SIGNATURE-----<br>
>><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>
><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>
<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>
</div></div></blockquote></div><br></div></div>