On Mon, Jan 20, 2014 at 03:09:14AM +0100, Tom Wijsman wrote: > On Sat, 18 Jan 2014 20:15:57 -0800 W. Trevor King wrote: > > On Sun, Jan 19, 2014 at 02:33:06AM +0100, Tom Wijsman wrote: > > > On Sat, 18 Jan 2014 15:24:59 -0800 W. Trevor King wrote: > > > > If it doesn't need to get updated, then it probably already > > > > started out explaining the consensus ;). > > > > > > That is a guess, you can look this up in past patches. > > > > Sure. Will you? If I want to touch some code, and it looks > > confusing, I'll use blame to see who wrote it and whay they were > > thinking about. If the commit message is not informative, I usually > > give up. I have a hard time imaging folks tracking down the thread > > that spawned that patch, assuming such a thread even exists, for each > > troublesome line they'd like to touch. It's much easier to summarize > > any issues the list resolved (because they're likely the same > > questions the new dev is asking) in the commit message, where future > > developers can find them. > > How does this make the consensus written after the patch part of it? > > The person whom commits can be different than the person whom wrote the > patch; and hence, that person commits without writing down consensus. > If that person were to write it down, it would change the authorship.
If the initial submission does not express the consensus, you can either ask for a resubmission that does, or say “Alice, is it ok if I change your commit message to read ‘…’? when I commit it?”. > Hence you made a guess, because I see pushed commits without > consensus. No policy/suggestion/goal is going to be followed 100% of the time. If most commits, especially those that were contentious enough to go through a few rounds of revision, have a commit message with a good summary, then the future developer using blame has good odds of finding something useful. I think that's a good goal to shoot for, even if you don't hit it all the time. Even if you only consider the present, improving your commit message to address tricky implementation details or unclear motivation before submitting the next revision on a patch series will help reviewers understand your patch better in the first place. > Here I like vapier's approach from the other reply in this sub > thread, that is to add it whenever people make the effort of > providing the tag; which is an approach the Linux kernel upstream > takes as well, if you want to be seen as a contributor you need to > provide the tags. Sounds fair to me. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
