On 06/16/2014 05:46 PM, Ben Nemec wrote: > On 06/16/2014 04:46 PM, Joe Gordon wrote: >> 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. > > I wonder if we should just make future hacking checks opt-in. Normally > I'd be opposed to that because in general people ignore opt-ins, but we > seem to have enough people using style changes as low-hanging-fruit to > get started that it might work in this case.
Whoops, forgot to credit Angus for the suggestion: http://lists.openstack.org/pipermail/openstack-dev/2014-June/037877.html > >> >> >>> >>> 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
