[PINGv2][PATCH v6] [gdb]: add git trailer information on gdb/MAINTAINERS

[Guinevere Larsen <blarsen@redhat.com>]

Ping!

-- 
Cheers,
Guinevere Larsen
She/Her/Hers
On 02/11/2023 14:54, Guinevere Larsen wrote:
> The project has been using Tested-By (tb), Reviewed-By (rb) and
> Approved-By (ab) for some time, but there has been no information to be
> found in the actual repository. This commit changes that by adding
> information about all git trailers to the MAINTAINERS file, so that it
> can be easily double-checked. Simply put, the trailers in use work as
> follows:
>
> * Tested-by: The person tested the patch and it fixes the problem, or
>    introduces no regressions (or both).
> * Acked-by: The general outline looks good, but the maintainer hasn't
>    looked at the code
> * Reviewed-by: The code looks good, but the reviewer has not approved
>    the patch to go upstream
> * Approved-by: The patch is ready to be pushed to master
>
> These last 3 trailers can also be restricted to one or more areas of GDB
> by adding the areas in a comma separated list in parenthesis after the
> trailers.
>
> Finally, for completeness sake, the trailers Co-Authored-By and Bug
> were added, even though they have been in use for a long time already
>
> ---
>   gdb/MAINTAINERS | 93 ++++++++++++++++++++++++++++++++++++++++++++-----
>   1 file changed, 85 insertions(+), 8 deletions(-)
>
> diff --git a/gdb/MAINTAINERS b/gdb/MAINTAINERS
> index 9989956065e..e1bb437a675 100644
> --- a/gdb/MAINTAINERS
> +++ b/gdb/MAINTAINERS
> @@ -43,14 +43,9 @@ patch without review from another maintainer.  This especially includes
>   patches which change internal interfaces (e.g. global functions, data
>   structures) or external interfaces (e.g. user, remote, MI, et cetera).
>   
> -The term "review" is used in this file to describe several kinds of feedback
> -from a maintainer: approval, rejection, and requests for changes or
> -clarification with the intention of approving a revised version.  Review is
> -a privilege and/or responsibility of various positions among the GDB
> -Maintainers.  Of course, anyone - whether they hold a position but not the
> -relevant one for a particular patch, or are just following along on the
> -mailing lists for fun, or anything in between - may suggest changes or
> -ask questions about a patch!
> +The word "contributor" is used in this document to refer to any GDB
> +developer listed above as well as folks who may have suggested some
> +patches but aren't part of one of those categories for any reason.
>   
>   There's also a couple of other people who play special roles in the GDB
>   community, separately from the patch process:
> @@ -78,6 +73,88 @@ consensus among the global maintainers and any other involved parties.
>   In cases where consensus can not be reached, the global maintainers may
>   ask the official FSF-appointed GDB maintainers for a final decision.
>   
> +The term "review" is used in this file to describe several kinds of
> +feedback from a maintainer: approval, rejection, and requests for changes
> +or clarification with the intention of approving a revised version.
> +Approval is a privilege and/or responsibility of various positions among
> +the GDB Maintainers.  Of course, anyone - whether they hold a position, but
> +not the relevant one for a particular patch, or are just following along on
> +the mailing lists for fun, or anything in between - may suggest changes, ask
> +questions about a patch or say if they believe a patch is fit for upstreaming!
> +
> +To ensure that patches are only pushed when approved, and to properly credit
> +the contributors who take the time to improve this project, the following
> +trailers are used to identify who contributed and how.  All patches pushed
> +upstream should have at least one Approved-By trailers (with the exception of
> +obvious patches, see below).  The trailers (or tags) currently in use are:
> +
> + - Tested-by:
> +
> +   Used when a contributor has tested the patch and finds that it
> +   fixes the claimed problem.  It may also be used to indicate that
> +   the contributor has performed regression testing.  By itself, this
> +   tag says nothing about the quality of the fix implemented by the
> +   patch, nor the amount of testing that was actually performed.
> +   Usage: "Tested-By: Your Name <your@email>"
> +
> + - Acked-By:
> +
> +   Used when a responsible or global maintaner has taken a superficial
> +   look at a patch and agree with its direction, but has not done further
> +   review on the subject.
> +   This trailer can be specific to one or more areas of the project, as
> +   defined by the "Responsible maintainers" section of this file.  If
> +   that is the case, the area(s) should be added at the end of the tag in
> +   parenthesis in a comma separated list.
> +   Usage: "Acked-By: Your Name <your@email> (area1, area2)"
> +
> + - Reviewed-by:
> +
> +   Used when a contributor has looked at the code and agrees with
> +   the changes, but either doesn't have the authority or doesn't
> +   feel comfortable approving the patch.
> +   This trailer can be specific to one or more areas of the project, as
> +   defined by the "Responsible maintainers" section of this file.  If
> +   that is the case, the area(s) should be added at the end of the tag in
> +   parenthesis in a comma separated list.
> +   Usage: "Reviewed-By: Your Name <your@email> (area1, area2)"
> +
> + - Approved-by:
> +
> +   Used by responsible maintainers or global maintainers when a patch is
> +   ready to be upstreamed.  If a patch requires multiple approvals, only
> +   the last reviewer should use this tag, making it obvious to the
> +   contributor that the patch is ready to be pushed.
> +   This trailer can be specific to one or more areas of the project, as
> +   defined by the "Responsible maintainers" section of this file.  If
> +   that is the case, the area(s) should be added at the end of the tag in
> +   parenthesis in a comma separated list.  Patches must have all areas
> +   approved before being pushed.  If a patch has had some areas approved,
> +   it is recommended that the final approver makes it explicit that the
> +   patch is ready for pushing.
> +   Responsible, Global and Official FSF-appointed maintainers may approve
> +   their own patches, but it is recommended that they seek external approval
> +   before doing so.
> +   Usage: "Approved-By: Your Name <your@email>"
> +
> + - Co-Authored-By:
> +
> +   Used when the commit includes meaningful conrtibutions from multiple people.
> +   Usage: "Co-Authored-By: Contributor's Name <their@email>"
> +
> + - Bug:
> +
> +   This trailer is added with a link to the GDB bug tracker bug for
> +   added context on relevant commits.
> +   Usage: "Bug: <link>"
> +
> +Sometimes, contributors may request small changes, such as fixing typos, before
> +granting the review or approval trailer. When the contributor thinks that
> +these changes are so small that it isn't necessary to send a new version, they
> +may add some text like "with these changes, I'm ok with the patch", followed by
> +their trailer.  In those situations, the trailer is only valid after the
> +changes are made.
> +
>   
>   			The Obvious Fix Rule
>   			--------------------