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