public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Bruno Larsen <blarsen@redhat.com>
To: gdb-patches@sourceware.org
Cc: gdb@sourceware.org, Bruno Larsen <blarsen@redhat.com>
Subject: [PATCH 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS
Date: Tue, 16 May 2023 16:38:27 +0200	[thread overview]
Message-ID: <20230516143826.3431583-2-blarsen@redhat.com> (raw)
In-Reply-To: <20230516143826.3431583-1-blarsen@redhat.com>

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.
---
 gdb/MAINTAINERS | 48 +++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 39 insertions(+), 9 deletions(-)

diff --git a/gdb/MAINTAINERS b/gdb/MAINTAINERS
index 175595d5f17..ba4fac2f0d1 100644
--- a/gdb/MAINTAINERS
+++ b/gdb/MAINTAINERS
@@ -43,15 +43,6 @@ 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!
-
 There's also a couple of other people who play special roles in the GDB
 community, separately from the patch process:
 
@@ -78,6 +69,45 @@ 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.  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!
+
+To ensure that patches are only pushed when approved, and to thank the
+contributors who take the time to review incoming patches, the GDB project
+uses git trailers to identify who contributed and how.  All patches pushed
+upstream should have at least one Approved-By patches (with the exception of
+obvious patches, see below).  The trailers (or tags) currently in use are:
+
+ - Tested-by:
+
+   Used when a contributor does not want to comment on the quality
+   of the code in the patch, but has tested and sees no regressions on their
+   hardware.
+
+ - Reviewed-by:
+
+   Used when a contributor has looked at code and agrees with the changes,
+   but either does not have the authority or doesn't feel comfortable
+   approving the patch (usually due to unfamiliarity with a certain
+   part of the code).
+
+ - Approved-by:
+
+   Used by responsible mainainers or global maintainers when
+   a patch is ready to be upstreamed.  Some patches may touch multiple areas
+   and require multiple approvals before landing (such as a maintainer only
+   approving documentation), it is up to the maintainer giving the approval tag
+   to make it clear when that a tag is not sufficient.
+   Responsible, Global and Official FSF-appointed maintainers may approve their
+   own patches, but it is recommended that they seek external approval before
+   doing so.
+
 
 			The Obvious Fix Rule
 			--------------------
-- 
2.40.1


  reply	other threads:[~2023-05-16 15:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-16 14:38 [PATCH 0/1] update MAINTAINERS file with git trailers Bruno Larsen
2023-05-16 14:38 ` Bruno Larsen [this message]
2023-05-16 16:04   ` [PATCH 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS Eli Zaretskii
2023-05-16 16:41     ` Bruno Larsen
2023-05-16 17:48       ` Eli Zaretskii
2023-05-16 19:40         ` Simon Marchi
2023-05-17  2:28           ` Eli Zaretskii
2023-05-17  8:19             ` Bruno Larsen
2023-05-17 14:35               ` Simon Marchi
2023-05-30  9:02 ` [PING][PATCH 0/1] update MAINTAINERS file with git trailers Bruno Larsen

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=20230516143826.3431583-2-blarsen@redhat.com \
    --to=blarsen@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=gdb@sourceware.org \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).