Open Stack

On Fri, Jun 20, 2014 at 11:33:30AM -0700, Joe Gordon wrote:
> 
> 
> 
> On Fri, Jun 20, 2014 at 11:07 AM, Sean Dague <sean at 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 at lists.openstack.org
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Petr Blaho, pblaho at redhat.com
Software Engineer