On Jun 16, 2014 10:02 AM, "Sean Dague" <[email protected]> wrote: > > On 06/16/2014 12:44 PM, Ben Nemec wrote: > > 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..." > > The challenge is that hacking updates are basically giant merge conflict > engines. If there is any significant amount of code outstanding in a > project, landing hacking only changes basically means requiring much of > the outstanding code to rebase. > > So it's actually expensive in a way that doesn't jump out immediately. > The cost of landing hacking isn't just the code of reviewing the hacking > patches, it's also the cost of the extra roundtrips on outstanding patches.
When a project chooses to enforce rules us decoupled with when hacking if released. So this sounds like a related yet different issue. > > > 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. > > I think both of those cases are really nits to the point that they > aren't worth enforcing. They won't change the correctness of the code. > And barely change the readability. > > There are differences with things like the is None checks, or python 3 > checks, which change correctness, or prevent subtle bugs. But I think > we're now getting to a level of cleanliness enforcement that trumps > functionally working. > > > 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. > > Actually, if you look at python novaclient, the doc string checks, which > are really niggly, and part of hacking are the biggest fails. It's much > less upstream that's doing this to us. > > > I could probably come up with a few more, but this is already too > > wall-of-texty for my tastes. :-) > > > > -Ben > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Sean Dague > http://dague.net > > > _______________________________________________ > 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
