On Mon, Jun 16, 2014 at 2:33 PM, Sean Dague <[email protected]> wrote: > On 06/16/2014 05:06 PM, Ben Nemec wrote: > > On 06/16/2014 12:01 PM, Sean Dague 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. > > > > If a project has that many violations of a new hacking rule then I'd > > say they should just leave it disabled. It already happens and I'd > > rather have that than throw out a rule just because some projects > > haven't been following it. > > That would be fine if the propose bot *also* proposed the tox.ini > ignores, which it does not. > > So it pushes a largely by definition broken patch that consumes > resources, and will require a human to take it over. If a person did > this on a regular basis, we'd have a stern talking to them. Or at least > a light making fun of them. > > It feels like robo auto propose should be limited to the class of things > where the patch is 99% sure to pass. >
I feel the same way on this one, for some reason I was originally under the impression that hacking had to manually be rolled out because of the reasons above. > > Which I think is really the crux of my distaste for hacking breaking > updates auto proposing to projects. > > -Sean > > -- > 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
