-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/16/2014 08:37 AM, Thierry Carrez wrote: > Sean Dague wrote: >> Hacking 0.9 series was released pretty late for Juno. The entire >> check queue was flooded this morning with requirements proposals >> failing pep8 because of it (so at 6am EST we were waiting 1.5 hrs >> for a check node). >> >> The previous soft policy with pep8 updates was that we set a >> pep8 version basically release week, and changes stopped being >> done for style after first milestone. >> >> I think in the spirit of that we should revert the hacking >> requirements update back to the 0.8 series for Juno. We're past >> milestone 1, so shouldn't be working on style only fixes at this >> point. >> >> Proposed review here - https://review.openstack.org/#/c/100231/ >> >> I also think in future hacking major releases need to happen >> within one week of release, or not at all for that series. > > We may also have reached a size where changing style rules is just > too costly, whatever the moment in the cycle. I think it's good > that we have rules to enforce a minimum of common style, but the > added value of those extra rules is limited, while their impact on > the common gate grows as we add more projects.
A few thoughts: 1) I disagree with the proposition that hacking updates can only happen in the first week after release. I get that there needs to be a cutoff, but I don't think one week is reasonable. Even if we release in the first week, you're still going to be dealing with hacking updates for the rest of the cycle as projects adopt the new rules at their leisure. I don't like retroactively applying milestone 1 as a cutoff either, although I could see making that the policy going forward. 2) Given that most of the changes involved in fixing the new failures are trivial, I think we should encourage combining the fixes into one commit. We _really_ don't need separate commits to fix H305 and H307. This doesn't help much with the reviewer load, but it should reduce the gate load somewhat. It violates the one change-one commit rule, but "A foolish consistency..." 3) We should start requiring specs for all new hacking rules to make sure we have consensus (I think oslo-specs is the place for this). 2 +2's doesn't really accomplish that. We also may need to raise the bar for inclusion of new rules - while I agree with all of the new ones added in hacking .9, I wonder if some of them are really necessary. 4) I don't think we're at a point where we should freeze hacking completely, however. The import grouping and long line wrapping checks in particular are things that reviewers have to enforce today, and that has a significant, if less well-defined, cost too. If we're really going to say those rules can't be enforced by hacking then we need to remove them from our hacking guidelines and start the long process of educating reviewers to stop requiring them. I'd rather just deal with the pain of adding them to hacking one time and never have to think about them again. I'm less convinced the other two that were added in .9 are necessary, but in any case these are discussions that should happen in spec reviews going forward. 5) We may want to come up with some way to globally disable pep8 checks we don't want to enforce, since we don't have any control over that but probably don't want to just stop updating pep8. That could make the pain of these updates much less. I could probably come up with a few more, but this is already too wall-of-texty for my tastes. :-) - -Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTnx7wAAoJEDehGd0Fy7uqoYAH/0KmxmR873Qn2Kti7LIEUNp4 1FJaBOX09ItxkkvyNRpcsIQu4fWycm60CckSOLfB7rgxgIjgsVkiZ9puE6oCmj2o Lhe5DhjYA2ROu9h8i0vmzYDnAKeu/WuRGtgyLSElUXeuiLpSrBcEA/03GpkCGiAP 1muAkVgv2oxDDwsaLwL7MmFrlZ1MPTP97lAfsfHbwbsOM5YMuPrRz9PirgHPBtTV 59UyofCGEBTtJKmJRLzRDZyDwTux5xrrc/cefer5GFLQH0ZbxOU1HHFESyc5wFVJ tI/3nPlbFpqCUtgmnQc8k3lX3d2H1Qr9UfCvYlJFTN1TmPmHmK378ioi81HoAVo= =tqtf -----END PGP SIGNATURE----- _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
