Excerpts from Morgan Fainberg's message of 2015-09-26 23:36:09 -0700:
> As a core (and former PTL) I just ignored commit message -1s unless there is 
> something majorly wrong (no bug id where one is needed, etc). 
> 
> I appreciate well formatted commits, but can we let this one go? This 
> discussion is so far into the meta-bike-shedding (bike shedding about bike 
> shedding commit messages) ... If a commit message is *that* bad a -1 (or just 
> fixing it?) Might be worth it. However, if a commit isn't missing key info 
> (bug id? Bp? Etc) and isn't one long incredibly unbroken sentence moving from 
> topic to topic, there isn't a good reason to block the review. 
> 
> It is not worth having a bot -1 bad commits or even having gerrit muck with 
> them. Let's do the job of the reviewer and actually review code instead of 
> going crazy with commit messages. 
> 

Agreed with all of your sentiments.

Please anyone -1'ing for this, read this:

https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_Git_commit_message_structure


"The first line should be limited to 50 characters and should not end
with a period (commit messages over 72 characters will be rejected by
the gate)."

"Subsequent lines should be wrapped at 72 characters."

Notice, the word "should" is used, not "must".

So _DO NOT_ -1 for this. A "should" is a guideline, and a note like
"hey could you wrap at 72 chars if you push again? We like to keep them
formatted that way, see [link] for more info. Thanks! #notAMinusOne"

Please can we not spend another minute on this? Thanks!

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to