[oe] Reverting recent openmoko commit

Philip Balister philip at balister.org
Mon Oct 27 10:39:29 UTC 2008


Phil Blundell wrote:
> On Sun, 2008-10-26 at 16:06 +0100, Koen Kooi wrote:
>> I'm going to revert all recent openmoko commits till these guys learn 
>> how to write a commit message. You have been warned before.
>>
>> In case you missed it, this wrong:
>>
>> [foo] something
> 
> This seems like an absurd over-reaction to something that is, at most, a
> trivial and merely technical breach of the checkin rules.  
> 
> Indeed, it is not even obvious that the original checkin breached any
> rule at all.  Where exactly is this strict format for commit messages
> documented?  The policy page at

I agree the reversion is an overreaction, but also understand this is 
not the first time this has happened. The messages I noticed that raised 
my eyebrows where some simple changes of description tags. The commit 
message was of the from "[description] Change package description". I 
try (when I have time" to inspect commits that impact stuff I care 
about. Messages of this form force me to read the diff to see what was 
impacted.

I disagree with the reversion as the changes I scanned were minor, but 
moving forward I would like to see better commit messages, even for what 
may be a trivial change to the author.

And yes, I'm sure I could dig through the changelog and find a crappy 
commit message from me to. And yes, I may have got the example message 
wrong because it is 0630 here, I am still in a time zone three hours 
west of here and I have a long day ahead.... Everyone needs to remember 
that behind every email message, irc remark, and commit message there is 
a living breathing person.

Philip

> http://wiki.openembedded.net/index.php/Commit_Policy doesn't seem to
> make mention of this.  The closest I could find was, under "other tips
> for making good commits":
> 
> * Have a clear commit message (example):
>     - The first line of commit is a summary of the changes.
>     - The first line should start with the name of the recipe the change affects.
> 
> and, as far as I can tell, the message that you quoted does indeed
> comply with these two guidelines, i.e. it contains the name of the
> recipe follows by a summary of the changes.  Nowhere on this page, or
> any other policy page that I found on quick inspection, were any further
> rules about what exactly constitutes an acceptable or unacceptable
> message.  In any case, further down the page is stated that "the above
> rules are not hard and fast rules": there is no indication that a
> non-conformant checkin message should lead to summary reversion of your
> changes.
> 
> The GitPhrasebook page does mention a more prescriptive format for
> checkin messages, but there is no indication that this is normative or
> forms a core part of OE policy.  (If it were, I would have expected to
> see it on the Commit Policy page, and/or to carry the imprimatur of the
> core team.)
> 
> All in all then, this whole episode appears rather like you have decided
> to enforce some arbitrary (and perhaps self-invented) rule for its own
> sake, rather than because there is actually an important point at issue.
> If true, that seems like inappropriate behaviour and, frankly, not
> something that is likely to enhance OE's reputation as a
> professionally-maintained tool for users to build their systems around.
> 
> So, please explain in more detail why you felt it was necessary to
> revert these changes without further discussion.  Was this a core team
> decision or did you act unilaterally?
> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20081027/53950d5d/attachment-0002.bin>


More information about the Openembedded-devel mailing list