[openstack-dev] [hacking] rules for removal

Sean Dague sean at dague.net
Sat Jun 21 12:08:01 UTC 2014

On 06/20/2014 09:26 PM, Clint Byrum wrote:
> Excerpts from Sean Dague's message of 2014-06-20 11:07:39 -0700:
>> 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).
> Yes. I despise this one.
>> 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.
> Perhaps we can make a bot that writes disparaging remarks on any -1's
> that mention "period" in the line after the short commit message. :)
>> 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.
> I think we should find a way to make this work. Like it or not, this
> will garner -1's by people for stylistic reasons and I'd rather it be
> the bots than the humans do it.
> The algorithm is something like this pseudo python:
> for block in import_blocks:
>     if is_this_set_in_a_known_lib_collection(block):
>         continue
>     if is_this_set_entirely_local(block):
>         continue
>     if is_this_set_entirely_installed_libs(block):
>         continue
>     raise AnError(block)
> And just make the python2 and python3 stdlibs both be a match. Basically
> I'm saying, let's just be more forgiving but keep the check so we can
> avoid most of the "-1 please group libs and stdlibs separately" patches.

You can avoid that by yelling at reviewers if that's the *only* feedback
they are giving.

Pedantic reviewers that are reviewing for this kind of thing only should
be scorned. I realistically like the idea markmc came up with -

I no longer buy the theory that something like this is saving time. What
it's actually doing is training a new generation of reviewers that the
right thing to do it review for nits. That's not actually what we want,
we want people reviewing for how this could go wrong.

It's really instructive to realize that we've definitely gone beyond
shared culture with what's in hacking. Look at how much of it is turned
off in projects. It's pretty high. If this project is going to remain
useful at all it really needs to prune back to what's actually shared


Sean Dague

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140621/1d0c1a20/attachment.pgp>

More information about the OpenStack-dev mailing list