1 |
On Sat, 18 Jan 2014 20:15:57 -0800 |
2 |
"W. Trevor King" <wking@×××××××.us> wrote: |
3 |
|
4 |
> On Sun, Jan 19, 2014 at 02:33:06AM +0100, Tom Wijsman wrote: |
5 |
> > On Sat, 18 Jan 2014 15:24:59 -0800 |
6 |
> > "W. Trevor King" <wking@×××××××.us> wrote: |
7 |
> > > If it doesn't need to get updated, then it probably already |
8 |
> > > started out explaining the consensus ;). |
9 |
> > |
10 |
> > That is a guess, you can look this up in past patches. |
11 |
> |
12 |
> Sure. Will you? If I want to touch some code, and it looks |
13 |
> confusing, I'll use blame to see who wrote it and whay they were |
14 |
> thinking about. If the commit message is not informative, I usually |
15 |
> give up. I have a hard time imaging folks tracking down the thread |
16 |
> that spawned that patch, assuming such a thread even exists, for each |
17 |
> troublesome line they'd like to touch. It's much easier to summarize |
18 |
> any issues the list resolved (because they're likely the same |
19 |
> questions the new dev is asking) in the commit message, where future |
20 |
> developers can find them. |
21 |
|
22 |
How does this make the consensus written after the patch part of it? |
23 |
|
24 |
The person whom commits can be different than the person whom wrote the |
25 |
patch; and hence, that person commits without writing down consensus. |
26 |
If that person were to write it down, it would change the authorship. |
27 |
|
28 |
Hence you made a guess, because I see pushed commits without consensus. |
29 |
|
30 |
> > > You spend time if you want to spend time and add whoever you feel |
31 |
> > > moved to add. |
32 |
> > |
33 |
> > We discuss whether to make it policy to add involved people. |
34 |
> |
35 |
> But “involved” can be hard to pin down, especially by someone who may |
36 |
> be applying v5 of a patch that hasn't been carefully following the |
37 |
> whole discussion in earlier versions. |
38 |
|
39 |
If this would be formalized, then v5 would include all tags until then. |
40 |
|
41 |
> The Linux kernel docs say [1]: |
42 |
> |
43 |
> If this patch fixes a problem reported by somebody else, consider |
44 |
> adding a Reported-by: tag to credit the reporter for their |
45 |
> contribution. |
46 |
> |
47 |
> Note the “consider” wiggle word. They are a bit more formal about |
48 |
> Reviewed-by, but only because it's signing off on their Reviewer's |
49 |
> statement of oversight. In general, if you're not signing some |
50 |
> statement with the tag, formalizing “involved” is hard. |
51 |
|
52 |
Here I like vapier's approach from the other reply in this sub thread, |
53 |
that is to add it whenever people make the effort of providing the tag; |
54 |
which is an approach the Linux kernel upstream takes as well, if you |
55 |
want to be seen as a contributor you need to provide the tags. |
56 |
|
57 |
> > > If you are submitting v2 of a patch, and feel a desire |
58 |
> > > to credit reviewers / testers with this syntax, I think that's |
59 |
> > > considerate of you. If you are committing someone else's patch to |
60 |
> > > master, and want to record the folks who acked it on the list to |
61 |
> > > distribute responsibility, that's fine too. If you want to use |
62 |
> > > another syntax, or not do any of this at all, it's still fine by |
63 |
> > > me ;). However, if a consistent syntax already exists, I see no |
64 |
> > > reason not to use it when it suits your purpose. |
65 |
> > |
66 |
> > We discuss here whether to make it policy to use the same syntax. |
67 |
> |
68 |
> I don't understand the distinction between “here are some guidelines, |
69 |
> apply as and if you see fit” and “make it a policy to …”. Say you |
70 |
> have a situation like this: |
71 |
|
72 |
When the thread starts with words like "ensure", "exercised", |
73 |
"followed", "should", "proposals" then I rather get the impression that |
74 |
this is rather working towards making it part of policy than some |
75 |
random guidelines; even if these words are not mentioned, it is for us |
76 |
to discuss whether we should make this more than just guidelines. |
77 |
|
78 |
> As I understand it, 6 should be: |
79 |
> |
80 |
> 6a. Everyone gets on with their lives. |
81 |
> |
82 |
> I could see a situation where: |
83 |
> |
84 |
> 6b. Charlie reminds Dan that he could have used the tags. Everyone |
85 |
> gets on with their lives. |
86 |
> |
87 |
> Is there another alternative step 6 implied by the “policy” keyword? |
88 |
> Or is the policy workflow even more different somehow? |
89 |
|
90 |
This discussion is based on that second situation 6b, as I think |
91 |
everyone is fine with 6a; but, some will want this to not become |
92 |
policy, others might want to see this to become policy. Hence this |
93 |
leads to a discussion. |
94 |
|
95 |
At the moment people seem fine with them being used optional, thus I |
96 |
agree with what was said here regarding it is a respectful suggestion to |
97 |
consider; at least nobody has strongly opposed to using them at all. |
98 |
|
99 |
-- |
100 |
With kind regards, |
101 |
|
102 |
Tom Wijsman (TomWij) |
103 |
Gentoo Developer |
104 |
|
105 |
E-mail address : TomWij@g.o |
106 |
GPG Public Key : 6D34E57D |
107 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |