<tt><font size=2>> From: Gorka Eguileor <geguileo@redhat.com></font></tt><br><tt><font size=2>> To: "OpenStack Development Mailing List
(not for usage questions)" <br>> <openstack-dev@lists.openstack.org></font></tt><br><tt><font size=2>> Date: 09/29/2015 07:34 AM</font></tt><br><tt><font size=2>> Subject: Re: [openstack-dev] [all] -1 due to
line length violation <br>> in commit messages</font></tt><br><tt><font size=2>...</font></tt><br><tt><font size=2>> Since we are not all native speakers expecting
everyone to realize that<br>> difference - which is completely right - may be a little optimistic,<br>> moreover considering that parts of those guidelines may even be written<br>> by non natives.<br>> <br>> Let's say I interpret all "should" instances in that guideline
as rules<br>> that don't need to be strictly enforced, I see that the Change-Id<br>> "should not be changed when rebasing" - this one would certainly
be fun<br>> to watch if we didn't follow it - the blueprint "should give
the name of<br>> a Launchpad blueprint" - I don't know any core that would not
-1 a patch<br>> if he notices the BP reference missing - and machine targeted metadata<br>> "should all be grouped together at the end of the commit message"
- this<br>> one everyone follows instinctively, so no problem.<br>> <br>> And if we look at the i18n guidelines, almost everything is using<br>> should, but on reviews these are treated as strict *must* because
of the<br>> implications.<br>> <br>> Anyway, it's a matter of opinion and afaik in Cinder we don't even
have<br>> a real problem with downvoting for the commit message length, I don't<br>> see more than 1 every couple of months or so.<br></font></tt><br><tt><font size=2>Other communities have solved this by explicit reference
to a standard defining terms like "must" and "should".</font></tt><br><br><tt><font size=2>Regards,</font></tt><br><tt><font size=2>Mike</font></tt><br><BR>