On Dec 9, 2014, at 10:05 AM, Sean Dague <s...@dague.net> wrote: > On 12/09/2014 09:11 AM, Doug Hellmann wrote: >> >> On Dec 9, 2014, at 6:39 AM, Sean Dague <s...@dague.net> wrote: >> >>> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely. >>> >>> 1 - the entire H8* group. This doesn't function on python code, it >>> functions on git commit message, which makes it tough to run locally. It >>> also would be a reason to prevent us from not rerunning tests on commit >>> message changes (something we could do after the next gerrit update). >>> >>> 2 - the entire H3* group - because of this - >>> https://review.openstack.org/#/c/140168/2/nova/tests/fixtures.py,cm >>> >>> A look at the H3* code shows that it's terribly complicated, and is >>> often full of bugs (a few bit us last week). I'd rather just delete it >>> and move on. >> >> I don’t have the hacking rules memorized. Could you describe them briefly? > > Sure, the H8* group is git commit messages. It's checking for line > length in the commit message. > > - [H802] First, provide a brief summary of 50 characters or less. Summaries > of greater then 72 characters will be rejected by the gate. > > - [H801] The first line of the commit message should provide an accurate > description of the change, not just a reference to a bug or > blueprint. > > > H802 is mechanically enforced (though not the 50 characters part, so the > code isn't the same as the rule). > > H801 is enforced by a regex that looks to see if the first line is a > launchpad bug and fails on it. You can't mechanically enforce that > english provides an accurate description.
Those all seem like things it would be reasonable to drop, especially for the reason you gave that they are frequently not tested locally anyway. > > > H3* are all the module import rules: > > Imports > ------- > - [H302] Do not import objects, only modules (*) > - [H301] Do not import more than one module per line (*) > - [H303] Do not use wildcard ``*`` import (*) > - [H304] Do not make relative imports > - Order your imports by the full module path > - [H305 H306 H307] Organize your imports according to the `Import order > template`_ and `Real-world Import Order Examples`_ below. > > I think these remain reasonable guidelines, but H302 is exceptionally > tricky to get right, and we keep not getting it right. I definitely agree with that. I thought we had it right now, but maybe there’s still a case where it’s broken? In any case, I’d like to be able to make the Oslo namespace changes API compatible without worrying about if they are hacking-rule-compatible. That does get pretty ugly. > > H305-307 are actually impossible to get right. Things come in and out of > stdlib in python all the time. +1 > > > I think it's time to just decide to be reasonable Humans and that these > are guidelines. I assume we have the guidelines written down in the review instructions somewhere already, if they are implemented in hacking? > > The H3* set of rules is also why you have to install *all* of > requirements.txt and test-requirements.txt in your pep8 tox target, > because H302 actually inspects the sys.modules to attempt to figure out > if things are correct. Yeah, that’s pretty gross. Doug > > -Sean > >> >> Doug >> - [H802] First, provide a brief summary of 50 characters or less. Summaries > of greater then 72 characters will be rejected by the gate. > > - [H801] The first line of the commit message should provide an accurate > description of the change, not just a reference to a bug or > blueprint. > >> >>> >>> -Sean >>> >>> -- >>> Sean Dague >>> http://dague.net >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > -- > Sean Dague > http://dague.net > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev