From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Git List <git@vger.kernel.org>,
Joshua Jensen <jjensen@workspacewhiz.com>,
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [PATCH v2 1/2] sh-setup: Write a new require_clean_work_tree function
Date: Fri, 1 Oct 2010 12:51:51 +0530 [thread overview]
Message-ID: <20101001072149.GA24171@kytes> (raw)
In-Reply-To: <20101001053721.GB6184@burratino>
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@gmail.com>
-- 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
next prev parent reply other threads:[~2010-10-01 7:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-30 20:03 [PATCH v2 0/2] Eliminate cryptic "needs update" error message Ramkumar Ramachandra
2010-09-30 20:03 ` [PATCH v2 1/2] sh-setup: Write a new require_clean_work_tree function Ramkumar Ramachandra
2010-09-30 20:38 ` Junio C Hamano
2010-10-01 4:57 ` Ramkumar Ramachandra
2010-10-01 5:37 ` Jonathan Nieder
2010-10-01 7:21 ` Ramkumar Ramachandra [this message]
2010-10-01 7:40 ` Jonathan Nieder
2010-10-01 12:56 ` Ramkumar Ramachandra
2010-10-01 18:28 ` Jonathan Nieder
2010-10-01 20:22 ` Sverre Rabbelier
2010-10-02 4:32 ` [PATCH v2 0/2] Eliminate cryptic "needs update" error message Ramkumar Ramachandra
2010-10-02 4:32 ` [PATCH v2 1/2] sh-setup: Write a new require_clean_work_tree function Ramkumar Ramachandra
2010-10-02 4:37 ` Ramkumar Ramachandra
2010-10-02 4:37 ` [PATCH] SubmittingPatches: Document some extra tags used in commit messages Ramkumar Ramachandra
2010-10-01 15:07 ` [PATCH v2 1/2] sh-setup: Write a new require_clean_work_tree function Junio C Hamano
2010-09-30 20:03 ` [PATCH v2 2/2] Porcelain scripts: Rewrite cryptic "needs update" error message Ramkumar Ramachandra
2010-09-30 21:08 ` Junio C Hamano
2010-10-01 5:14 ` Ramkumar Ramachandra
2010-10-03 23:34 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101001072149.GA24171@kytes \
--to=artagnon@gmail.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jjensen@workspacewhiz.com \
--cc=jrnieder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).