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. Which I think is really the crux of my distaste for hacking breaking updates auto proposing to projects. -Sean -- Sean Dague http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev