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