Proposal: Add review tags to patch review workflow.

Bruno Larsen
Mon Oct 10 09:27:03 GMT 2022

On 08/10/2022 14:44, Eli Zaretskii wrote:
>> Date: Sat, 8 Oct 2022 07:55:00 -0400
>> Cc:,
>> From: Simon Marchi <>
>> On 2022-10-08 02:23, Eli Zaretskii wrote:
>>>> Date: Fri, 7 Oct 2022 16:46:23 -0400
>>>> From: Simon Marchi via Gdb <>
>>>> We don't really have a formal process for voting / adopting proposals
>>>> like this.  Given there was no negative feedback at all (from what I
>>>> remember), please go ahead and update the wiki.  I will try to remember
>>>> to use the tags from now on.
>>> It would help if the new rules for using the tags were posted here as
>>> well, I think.  Then, if someone has questions or wants to request
>>> clarifications, they could do that right away, instead of waiting
>>> until the first time they need to use the new rules.
>> They were explained in Bruno's original message, and Bruno will add them
>> to the wiki.
> They were followed by discussion and some changes, AFAIR.  Also, the
> original post was quite long, so I hoped for a concise version akin a
> cookbook.
As Simon mentioned, there weren't big changes, but here's a quick cookbook:

1. If you have the authority to approve a patch and believe the patch 
you are reviewing is ready to be merged, add the following line to your 
e-mail (usually at the end): Approved-by: Your Name <>

2. If you don't have the authority to approve patches, or aren't 
convinced that you know enough about the area of code to fully approve a 
patch for merging, and haven't found any technical issues (i.e. 
non-nitpicks) with the patch, add the following line to your e-mail: 
Reviewed-by: Your Name <>

3. If you aren't sure of the quality of the technical changes, but you 
have tested and verified that the patch does not add any regressions, 
add the following line to your e-mail: Tested-by: Your Name 

I hope this clears up any confusion!


More information about the Gdb mailing list