On Fri, Jun 20, 2014 at 11:33:30AM -0700, Joe Gordon wrote: > > > > On Fri, Jun 20, 2014 at 11:07 AM, Sean Dague <s...@dague.net> wrote: > > After seeing a bunch of code changes to enforce new hacking rules, I'd > like to propose dropping some of the rules we have. The overall patch > series is here - > https://review.openstack.org/#/q/status:open+project:openstack-dev/ > hacking+branch:master+topic:be_less_silly,n,z > > H402 - 1 line doc strings should end in punctuation. The real statement > is this should be a summary sentence. A sentence is not just a set of > words that end in a period. Squirel fast bob. It's something deeper. > This rule thus isn't really semantically useful, especially when you are > talking about at 69 character maximum (79 - 4 space indent - 6 quote > characters). > > > Thoughts on removing all pep257 (http://legacy.python.org/dev/peps/pep-0257/) > things from hacking? If projects would still like to enforce it there is a > flake8 extension for pep257 itself. > > +1 - why to invent wheel again?
> > H803 - First line of a commit message must *not* end in a period. This > was mostly a response to an unreasonable core reviewer that was -1ing > people for not having periods. I think any core reviewer that -1s for > this either way should be thrown off the island, or at least made fun > of, a lot. Again, the clarity of a commit message is not made or lost by > the lack or existence of a period at the end of the first line. > > > ++ for removing this, in general the git based rules are funny to enforce. As > you can run 'tox -epep8' before a commit and everything will pass, then you > write your commit message and now it will fail. > +1 I have seen exactly this to happen. > > > H305 - Enforcement of libraries fitting correctly into stdlib, 3rdparty, > our tree. This biggest issue here is it's built in a world where there > was only 1 viable python version, 2.7. Python's stdlib is actually > pretty dynamic and grows over time. As we embrace more python 3, and as > distros start to make python3 be front and center, what does this even > mean? The current enforcement can't pass on both python2 and python3 at > the same time in many cases because of that. > > > ++ Oh Python 2 vs. 3 > > For this one I think we should leave the rule in HACKING.rst but explicitly > document it as a recommendation, and that python2 vs python3 makes this > unenforceable. > +1 I like the idea of these unnenforced recommendations. HACKING.rst as a guide and hacking tool as strict enforcer for guide's subset. > > > We have to remember we're all humans, and it's ok to have grey space. > Like in 305, you *should* group the libraries if you can, but stuff like > that should be labeled as 'nit' in the review, and only ask the author > to respin it if there are other more serious issues to be handled. > > Let's optimize a little more for fun, and stop throwing -1s for silly > things. :) > > -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 -- Petr Blaho, pbl...@redhat.com Software Engineer _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
