Another idea I had: It appears like a lot of the current hacking issues can be automatically fixed.
So it would be really nice if the hacking tool included a fix for most of the problems it finds. I started https://review.openstack.org/#/c/68988/ but don't have the time to do a full tool, but it would be nice if the hacking tool/proposal bot/other would propose fixes by itself for most of the 'autofixable' issues (like imports being in the wrong order or not in the right grouping). That'd help in avoiding a ton of less useful commits to fix those same issues manually. -Josh -----Original Message----- From: Sean Dague <[email protected]> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> Date: Monday, June 16, 2014 at 5:15 AM To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> Subject: [openstack-dev] revert hacking to 0.8 series >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. > > -Sean > >-- >Sean Dague >http://dague.net > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
