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 - https://twitter.com/markmc_/status/480073387600269312 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 culture. -Sean -- Sean Dague http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev