git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] SubmittingPatches: Document how to request a patch review tag

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 6, 2013, 09:01 UTC
Message-ID
<7vtxquofbd.fsf@alter.siamese.dyndns.org>
In-Reply-To
<50E92875.6080305@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 14 quoted lines
> On 01/04/2013 10:47 PM, Junio C Hamano wrote:
>> "Reviewed-by" is for those who are familiar with the part of the
>> system being touched to say "I reviewed this patch, it looks good",
>> and Michael indeed was involved in recent updates to the refs.c
>> infrastructure, so as he said in his message "it looks like I should",
>> it was the right thing to do.
>>
>> I do not think Michael was asking if that was the standard _thing_
>> to do; I think the question was if there was a standard _way_
>> (perhaps a tool) to send such a "Reviewed-by:" line.
>
> Junio is correct; I was just asking whether there was a particular email
> convention for adding a "Reviewed-by:" line.  It would be nice for this
> to be mentioned in the documentation.

Yeah, I wasn't exactly correct in that I was talking more about Acked-by than Reviewed-by, but they are morally very similar and the same argument applies to both.

In the particular case of your "refs.c" review, because you are not just familiar with the code, but essentially are the current owner of the code, Acked-by might have been even more appropriate than Reviewed-by, by the way.

Show 11 quoted lines
>> +If you are a reviewer and wish to add your Acked-by/Reviewed-by/Tested-by tag
>> +to a patch series under discussion (after having reviewed it or tested it
>> +of course!), reply to the author of the patch series, cc'ing the git mailing
>> +list.
>> +
>>  You can also create your own tag or use one that's in common usage
>>  such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".
>
> I don't think this is quite correct.  Such emails should be
> "reply-to-all" people who have participated in the thread, which might
> include more than just the patch author and the git mailing list.

That would be more helpful. In practice, I can pick these up either way, but Cc'ing everybody would be better as a common courtesy.

When the author resubmits an already reviewed patch with these Acks and Reviews for final application, these reviewers should be Cc'ed so that they can say "Huh? that is not the exact patch I reviewed. What is going on?".

Thanks for a review.
Previous: Michael HaggertyNext: Junio C Hamano
Message 10 of 12 in “Update SubmittingPatches”
  1. 0/3 Update SubmittingPatchesJunio C Hamano, Jan 1, 2013
  2. 1/3 SubmittingPatches: who am I and who cares?Junio C Hamano, Jan 1, 2013
  3. 2/3 SubmittingPatches: mention subsystems with dedicated repositoriesJunio C Hamano, Jan 1, 2013
  4. Jason HoldenJan 2, 2013
  5. Junio C HamanoJan 2, 2013
  6. Junio C HamanoJan 2, 2013
  7. SubmittingPatches: Document how to request a patch review tagJason Holden, Jan 4, 2013
  8. Junio C HamanoJan 4, 2013
  9. Michael HaggertyJan 6, 2013
  10. Junio C HamanoJan 6, 2013
  11. 3/3 SubmittingPatches: remove overlong checklistJunio C Hamano, Jan 1, 2013
  12. Jeff KingJan 2, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.