From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: 66436@debbugs.gnu.org
Cc: dev@jpoiret.xyz, ludo@gnu.org,
Maxim Cournoyer <maxim.cournoyer@gmail.com>,
zimon.toutoune@gmail.com
Subject: [bug#66436] [PATCH v3] doc: Add some guidelines for reviewing.
Date: Wed, 1 Nov 2023 15:23:23 -0400 [thread overview]
Message-ID: <ee8182cae8ec18eedbef416483701e60da123e6a.1698866603.git.maxim.cournoyer@gmail.com> (raw)
In-Reply-To: <19f82d9bbef649c750ad067d23ebbaee6f9ae494.1696942467.git.maxim.cournoyer@gmail.com>
* doc/contributing.texi (Contributing) [Reviewing the Work of Others]: New
section.
(Debbugs Usertags): Expound with Emacs Debbugs information and document the
'reviewed-looks-good' usertag.
Change-Id: I56630b15ec4fbc5c67e5420dbf2838556a005d6b
---
Changes in v3:
- Replace LGTM with Reviewed-by Git tag
- Add b4 config
- Link to the Submitting Patches section for check list
- Fuse further suggestions by both Ludovic and Simon
doc/contributing.texi | 111 ++++++++++++++++++++++++++++++++++++++++--
etc/git/gitconfig | 7 +++
2 files changed, 114 insertions(+), 4 deletions(-)
diff --git a/doc/contributing.texi b/doc/contributing.texi
index 30876447d4..023478c98d 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -29,6 +29,7 @@ Contributing
* Submitting Patches:: Share your work.
* Tracking Bugs and Changes:: Keeping it all organized.
* Commit Access:: Pushing to the official repository.
+* Reviewing the Work of Others:: Some guidelines for sharing reviews.
* Updating the Guix Package:: Updating the Guix package definition.
* Writing Documentation:: Improving documentation in GNU Guix.
* Translating Guix:: Make Guix speak your native language.
@@ -1981,7 +1982,12 @@ Debbugs Usertags
tag any bug with an arbitrary label. Bugs can be searched by usertag,
so this is a handy way to organize bugs@footnote{The list of usertags is
public information, and anyone can modify any user's list of usertags,
-so keep that in mind if you choose to use this feature.}.
+so keep that in mind if you choose to use this feature.}. If you use
+Emacs Debbugs, the entry-point to consult existing usertags is the
+@samp{C-u M-x debbugs-gnu-usertags} procedure. To set a usertag, press
+@samp{C} while consulting a bug within the *Guix-Patches* buffer opened
+with @samp{C-u M-x debbugs-gnu-bugs} buffer, then select @code{usertag}
+and follow the instructions.
For example, to view all the bug reports (or patches, in the case of
@code{guix-patches}) tagged with the usertag @code{powerpc64le-linux}
@@ -1994,9 +2000,9 @@ Debbugs Usertags
to interact with Debbugs.
In Guix, we are experimenting with usertags to keep track of
-architecture-specific issues. To facilitate collaboration, all our
-usertags are associated with the single user @code{guix}. The following
-usertags currently exist for that user:
+architecture-specific issues, as well as reviewed ones. To facilitate
+collaboration, all our usertags are associated with the single user
+@code{guix}. The following usertags currently exist for that user:
@table @code
@@ -2014,6 +2020,9 @@ Debbugs Usertags
appropriate to assign this usertag to a bug report for a package that
fails to build reproducibly.
+@item reviewed-looks-good
+You have reviewed the series and it looks good to you (LGTM).
+
@end table
If you're a committer and you want to add a usertag, just start using it
@@ -2283,6 +2292,100 @@ Commit Access
you're welcome to use your expertise and commit rights to help other
contributors, too!
+@node Reviewing the Work of Others
+@section Reviewing the Work of Others
+
+Perhaps the biggest action you can do to help GNU Guix grow as a project
+is to review the work contributed by others. You do not need to be a
+committer to do so; applying, reading the source, building, linting and
+running other people's series and sharing your comments about your
+experience will give some confidence to committers. Basically, you gmust
+ensure the check list found in the @ref{Submitting Patches} section has
+been correctly followed. A reviewed patch series should give the best
+chances for the proposed change to be merged faster, so if a change you
+would like to see merged hasn't yet been reviewed, this is the most
+appropriate thing to do!
+
+@cindex reviewing, guidelines
+Review comments should be unambiguous; be as clear and explicit as you
+can about what you think should be changed, ensuring the author can take
+action on it. Please try to keep the following guidelines in mind
+during review:
+
+@enumerate
+@item
+@emph{Be clear and explicit about changes you are suggesting}, ensuring
+the author can take action on it. In particular, it is a good idea to
+explicitly ask for new revisions when you want it.
+
+@item
+@emph{Remain focused: do not change the scope of the work being
+reviewed.} For example, if the contribution touches code that follows a
+pattern deemed unwieldy, it would be unfair to ask the submitter to fix
+all occurrences of that pattern in the code; to put it simply, if a
+problem unrelated to the patch at hand was already there, do not ask the
+submitter to fix it.
+
+@item
+@emph{Ensure progress.} As they respond to review, submitters may
+submit new revisions of their changes; avoid requesting changes that you
+did not request in the previous round of comments. Overall, the
+submitter should get a clear sense of progress; the number of items open
+for discussion should clearly decrease over time.
+
+@item
+@emph{Aim for finalization.} Reviewing code is time-consuming. Your
+goal as a reviewer is to put the process on a clear path towards
+integration, possibly with agreed-upon changes, or rejection, with a
+clear and mutually-understood reasoning. Avoid leaving the review
+process in a lingering state with no clear way out.
+
+@item
+@emph{Review is a discussion.} The submitter's and reviewer's views on
+how to achieve a particular change may not always be aligned. To lead
+the discussion, remain focused, ensure progress and aim for
+finalization, spending time proportional to the stakes@footnote{The
+tendency to discuss minute details at length is often referred to as
+``bikeshedding'', where much time is spent discussing each one's
+preference for the color of the shed at the expense of progress made on
+the project to keep bikes dry.}. As a reviewer, try hard to explain the
+rationale for suggestions you make, and to understand and take into
+account the submitter's motivation for doing things in a certain way.
+@end enumerate
+
+@cindex LGTM, Looks Good To Me
+@cindex review tags
+@cindex Reviewed-by, git trailer
+When you deem the proposed change adequate and ready for inclusion
+within Guix, the following well understood/codified
+@samp{Reviewed-by:@tie{}Your@tie{}Name<your-email@@example.com>}
+@footnote{The @samp{Reviewed-by} Git trailer is used by other projects
+such as Linux, and is understood by third-party tools such as the
+@samp{b4 am} sub-command, which is able to retrieve the complete
+submission email thread from a public-inbox instance and add the Git
+trailers found in replies to the commit patches.} line should be used to
+sign off as a reviewer, meaning you have reviewed the change and that it
+looks good to you:
+
+@itemize
+@item
+If the @emph{whole} series (containing multiple commits) looks good to
+you, reply with @samp{Reviewed-by:@tie{}Your@tie{}Name<your-email@@example.com>}
+to the cover page if it has one, or to the last patch of the series
+otherwise, adding another @samp{(for the whole series)} comment on the
+line below to explicit this fact.
+
+@item
+If you instead want to mark a @emph{single commit} as reviewed (but not
+the whole series), simply reply with
+@samp{Reviewed-by:@tie{}Your@tie{}Name<your-email@@example.com>} to that
+commit message.
+@end itemize
+
+If you are not a committer, you can help others find a @emph{series} you
+have reviewed more easily by adding a @code{reviewed-looks-good} usertag
+for the @code{guix} user (@pxref{Debbugs Usertags}).
+
@node Updating the Guix Package
@section Updating the Guix Package
diff --git a/etc/git/gitconfig b/etc/git/gitconfig
index 907ad01804..654a630b18 100644
--- a/etc/git/gitconfig
+++ b/etc/git/gitconfig
@@ -16,3 +16,10 @@
to = guix-patches@gnu.org
headerCmd = etc/teams.scm cc-members-header-cmd
thread = no
+
+[b4]
+ attestation-check-dkim = off
+ attestation-policy = off
+ linkmask = https://yhetil.org/guix/%s
+ linktrailermask = https://yhetil.org/guix/%s
+ midmask = https://yhetil.org/guix/%s
base-commit: a96f1c1bc0fa186414359890025e8acacbb1de02
--
2.41.0
next prev parent reply other threads:[~2023-11-01 19:24 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 12:54 [bug#66436] [PATCH] doc: Add some guidelines for reviewing Maxim Cournoyer
2023-10-10 13:29 ` Ludovic Courtès
2023-10-11 0:24 ` [bug#66436] [PATCH v2] " Maxim Cournoyer
2023-10-15 9:55 ` Josselin Poiret via Guix-patches via
2023-10-16 14:02 ` Maxim Cournoyer
2023-10-29 14:52 ` Josselin Poiret via Guix-patches via
2023-10-20 8:12 ` Clément Lassieur
2023-10-20 23:01 ` Maxim Cournoyer
2023-10-22 20:03 ` Clément Lassieur
2023-10-23 1:55 ` Maxim Cournoyer
2023-10-24 8:49 ` Simon Tournier
2023-10-24 8:59 ` Simon Tournier
2023-10-31 18:53 ` Maxim Cournoyer
2023-10-31 19:03 ` Simon Tournier
2023-10-24 15:54 ` Ludovic Courtès
2023-10-25 13:53 ` Simon Tournier
2023-10-12 2:48 ` [bug#66436] [PATCH 0/2] Add support for Git Large File Storage (LFS) Maxim Cournoyer
2023-10-12 2:51 ` Maxim Cournoyer
2023-10-31 20:25 ` [bug#66475] [PATCH v2 1/4] git-download: " Maxim Cournoyer
2023-10-31 20:25 ` [bug#66475] [PATCH v2 2/4] gnu: mdds: Update to 2.1.1 Maxim Cournoyer
2023-10-31 20:25 ` [bug#66475] [PATCH v2 3/4] gnu: ixion: Update to 0.19.0 Maxim Cournoyer
2023-10-31 20:25 ` [bug#66475] [PATCH v2 4/4] gnu: orcus: " Maxim Cournoyer
2023-11-05 14:49 ` [bug#66475] [PATCH v2 1/4] git-download: Add support for Git Large File Storage (LFS) Ludovic Courtès
2023-11-07 16:17 ` bug#66475: " Maxim Cournoyer
2023-11-01 19:23 ` Maxim Cournoyer [this message]
2023-11-05 14:51 ` [bug#66436] [PATCH v3] doc: Add some guidelines for reviewing Ludovic Courtès
2023-11-07 16:14 ` bug#66436: " Maxim Cournoyer
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=ee8182cae8ec18eedbef416483701e60da123e6a.1698866603.git.maxim.cournoyer@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=66436@debbugs.gnu.org \
--cc=dev@jpoiret.xyz \
--cc=ludo@gnu.org \
--cc=zimon.toutoune@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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.