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. > > >> >> 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
