On Mon, Jun 16, 2014 at 2:56 PM, Doug Hellmann <doug.hellm...@dreamhost.com> wrote:
> On Mon, Jun 16, 2014 at 2:23 PM, Joe Gordon <joe.gord...@gmail.com> wrote: > > > > On Jun 16, 2014 9:44 AM, "Ben Nemec" <openst...@nemebean.com> 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. > > You wouldn't need a new repo. Hacking is part of the Oslo program, so > you would use oslo-specs just like the other Oslo projects. > > The process you describe is what we've done historically, but as we > standardize on specs repos we will want to eventually reconsider it. > If the point of posting to the mailing list is to encourage > discussion, then it seems like that step could be replaced with a > spec. > Perhaps, I still am not sure how that really helps. > > Doug > > > > >> 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 > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
