Reverting recent openmoko commit

Reverting recent openmoko commit

[Koen Kooi]

Hi,

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

Re: Reverting recent openmoko commit

[Michael 'Mickey' Lauer]

Ok, Koen, you are going too far now.

I have tolerated your self-elected-sheriff-behaviour over the years
since you were important for OE, even if you scared people away and
endangered OE's public relation through your disrespectful and hostile
behaviour. I'm fed up with you and your attitude and this has to and
will stop now in one way or the other.

Sincerely,

Mickey.

Re: Reverting recent openmoko commit

[Phil Blundell]

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
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.

Re: Reverting recent openmoko commit

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 3785 bytes --]

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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Reverting recent openmoko commit

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 3785 bytes --]

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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Reverting recent openmoko commit

[Michael Krelin]

What I fail to see is how does reverting commits improve history.

What I do see is that the reverting commits do not adhere to the policy 
in question ;-)

Love,
H

Koen Kooi wrote:
> Hi,
> 
> 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
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Policies vs. Guidelines vs. Requirements (was: Reverting recent openmoko commit)

[Michael 'Mickey' Lauer]

Guys,

to me these "policies" were always more guidelines than strict requirements. 
We are not a beaurocratic institute here or a closed company (where you can 
feel free to impose them if you want), but rather a bunch people working 
together on a somewhat common goal.

As such it's _completely unacceptable_ to revert a whole lot of valuable work 
just because some of the guidelines were not enforced 100%. Completely 
unacceptable. Also unacceptable is a one-man-show revertion without a 
consensus, but that's something the core team has to discuss.

Nearbye, _if_ the core team can find a majority to make these kind of policies 
strict requirements, then the ones in favour of this solution should come up 
with git commit hooks, so that the commits violating the policy can not be 
commited in the first place.

In the meantime I'd be very happy if Holger would reapply his changes.
-- 
:M:

Re: Policies vs. Guidelines vs. Requirements

[Michael Krelin]

> to me these "policies" were always more guidelines than strict requirements. 
> We are not a beaurocratic institute here or a closed company (where you can 
> feel free to impose them if you want), but rather a bunch people working 
> together on a somewhat common goal.

I think this is very important statement. Because it really feels weird 
in the *free* as in freedom world to be forced into any requirements 
like that. Especially now that we have git, which may also benefit from 
'pull model' and the very idea of having not to pull branches for the 
sole reason that weeks ago they've *commented* on something the way we 
wouldn't.

> As such it's _completely unacceptable_ to revert a whole lot of valuable work 
> just because some of the guidelines were not enforced 100%. Completely 
> unacceptable. Also unacceptable is a one-man-show revertion without a 
> consensus, but that's something the core team has to discuss.

I think Koen is smart enough to understand that these reverts do not 
improve history in any way, so I'd say that it's the result of 
frustration with these messages. While I do not approve of it, you 
should keep in mind that behind the name "Koen" there is also a 
breathing person.

> In the meantime I'd be very happy if Holger would reapply his changes.

Why not angrily revert the reverts? ;-)

Love,
H

Re: Reverting recent openmoko commit

[Holger Freyther]

On Monday 27 October 2008 11:37:24 Philip Balister wrote:

> 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.

The difficulty is. The original above commit touched ~40 recipes, now many of 
these changes do not apply because the recipes that are touched changed, are 
not there any more, or not yet merged.

I'm basically in this dilemma:
	- Copy everything from OM over and have one commit... I personally hate this 
as we lose the history of the changes, I don't credit the creators properly. I 
hope there is an agreement.

       - I could rewrite every commit message. I have to admit I'm too lazy to 
spend two weeks in rewriting every single commit message. I would have to 
resort to the above which I think is  a bad idea.

      -  I can merge as I did. The changes (at least at the end of the chain) 
are sensible and should follow common practices. The commit messages are not 
perfect (in the case that they use [] instead of :). From the possible options 
I see this is the best. As this is crediting people properly (encouraging them 
to do more work), it is preserving history (the distance between commits, the 
authors, the reasoning is still there) and it is not doing any damage.

Where from here?
	- I will merge yesterday's work again as is?
	- I will ask our OM developers to use a different style in the commit message 
(even if this is not mandated) to not use braces but colons. And yes I think I 
asked them to use [] as I'm used to this from various other projects, I will 
ask them to change and change it myself.


z.

Re: Reverting recent openmoko commit

[Michael 'Mickey' Lauer]

> Where from here?
> 	- I will merge yesterday's work again as is?

Yes.

> 	- I will ask our OM developers to use a different style in the commit
> message (even if this is not mandated) to not use braces but colons. And
> yes I think I asked them to use [] as I'm used to this from various other
> projects, I will ask them to change and change it myself.

Sounds good. Again, my take on this is: These policies are guidelines, not 
strict requirements. If we decide otherwise, we need to have restrictive 
commit hooks or switch over to a completely different model of working 
together.

-- 
:M:

Re: Reverting recent openmoko commit

[Michael Krelin]

> 	- I will ask our OM developers to use a different style in the commit message 
> (even if this is not mandated) to not use braces but colons. And yes I think I 
> asked them to use [] as I'm used to this from various other projects, I will 
> ask them to change and change it myself.

I think the problem was not purely syntactical, the problem is that the 
commit subject did not always mention the recipe in question, but rather 
"Description", "alias name", etc.


Love,
H

Re: Reverting recent openmoko commit

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]

Michael 'Mickey' Lauer wrote:
>> Where from here?
>> 	- I will merge yesterday's work again as is?
> 
> Yes.
> 
>> 	- I will ask our OM developers to use a different style in the commit
>> message (even if this is not mandated) to not use braces but colons. And
>> yes I think I asked them to use [] as I'm used to this from various other
>> projects, I will ask them to change and change it myself.
> 
> Sounds good. Again, my take on this is: These policies are guidelines, not 
> strict requirements. If we decide otherwise, we need to have restrictive 
> commit hooks or switch over to a completely different model of working 
> together.

I agree we do not want restrictive guidelines. I'm also glad to see that 
OpenMoko is willing to modify their commit messages to match the 
OpenEmbedded format.

Hopefully, all projects that plan to feed changes into the core 
OpenEmbedded repository will use the same commit message format. The 
weekly change log shows why it is useful to standardize the commit 
message. Both formats in use are readable, but switching from one to the 
other when skimming is difficult.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]