[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