On Jun 16, 2014 9:44 AM, "Ben Nemec" <[email protected]> wrote: > > -----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).
This is a general issue with global requirements, the number of jobs we run and the number of available nodes. Let's solve the general case. > >> > >> 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. > I would rather just have more folks review hacking patches then add a specs repo. A specs repo is overkill, IMHO, hacking doesn't have that many patches per cycle. In general when adding a rule to hacking it has to already be in HACKING.rst and/or needs a ML post. > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
