Re: [PATCH v2 1/2] sh-setup: Write a new require_clean_work_tree function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jonathan,

Jonathan Nieder writes:
> Some noise about Cc and Reviewed-by tags:
> 
>  - I have been using Cc lines in patches to say "I consider this
>    person something of a maintainer of the subsystem in question
>    and would be particularly interested in his or her opinion."
>    The idea is that if the patch does not get acked and a Cc line
>    remains, people can tell that from the log.  The benefits:
> 
>     1) I remember to cc them
>     2) later it is easy to find who looks like a maintainer
>     3) the lack of ack is more obvious
> 
>    Checking Linux's Documentation/SubmittingPatches, I find that
>    that is a misuse on my part (sorry).  A person passing on a patch
>    to Linus is rather supposed to _add_ a Cc line in the rare event
>    that they want to explain that a certain person had an opportunity
>    to comment but did not comment (so Linus can know about their
>    indifference to the patch, I guess).
> 
>    Neither use is as important for git, where many people read the
>    list so it is not as important to cc people to get proper review.
> 
>  - I also used to abuse Cc lines to fit in contact information for a
>    person who helped me, until I learned to use Helped-by and similar
>    neologisms for that.  Sorry.
> 
>  - Again from Documentation/SubmittingPatches, I learned a while ago
>    that Reviewed-by, unlike Acked-by, can only be offered by the
>    reviewer and means that she is satisfied that the patch is ready
>    for application.
> 
> If you just want to credit Matthieu, I suppose it would make sense to
> say "Thanks to Matthieu Moy for such-and-such" somewhere.

Thanks for the lengthy explanation. Perhaps we can document this in
Git's SubmittingPatches?

Are all these tags useful? Should I include more such as "Mentored-by"
or explicity mention that the contributor is free to come up with
other freeform tags as she deems appropriate?

Signed-off-by: Ramkumar Ramachandra <artagnon@xxxxxxxxx>
-- 8< --
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index ece3c77..84c9eaa 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -264,12 +264,25 @@ the change to its true author (see (2) above).
 Also notice that a real name is used in the Signed-off-by: line. Please
 don't hide your real name.
 
-Some people also put extra tags at the end.
-
-"Acked-by:" says that the patch was reviewed by the person who
-is more familiar with the issues and the area the patch attempts
-to modify.  "Tested-by:" says the patch was tested by the person
-and found to have the desired effect.
+Some extra tags you can use in the end along with their meanings are:
+
+1. "Reported-by:" is used to to credit someone who found the bug that
+   the patch attempts to fix.
+2. "Acked-by:" says that the patch was acknowledged by the person who
+   is more familiar with the issues and the area the patch attempts to
+   modify.
+3. "Reviewed-by:", unlike the other tags, can only be offered by the
+   reviewer and means that she is completely satisfied that the patch
+   is ready for application.  It is usually offered only after a
+   detailed review.
+4. "Tested-by:" is used to indicate that the person applied the patch
+   and found it to have the desired effect.
+5. "Thanks-to:" is a more broad term used to credit someone who helped
+   with the patch in some way. The person perhaps gave an idea or
+   reviewed some part of the patch without awarding a "Reviewed-by".
+6. "Based-on-patch-by:" is used to credit the person whose patch yours
+   is based on. The original patch was probably not considered for
+   inclusion due to several reasons.
 
 ------------------------------------------------
 An ideal patch flow
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]