--- Begin Message ---
|
Subject: |
[PATCH] doc: Add some guidelines for reviewing. |
|
Date: |
Tue, 10 Oct 2023 08:54:27 -0400 |
* doc/contributing.texi (Contributing) [Reviewing the Work of Others]: New
section.
* doc/contributing.texi (Debbugs Usertags): Expound with Emacs Debbugs
information and document the 'reviewed-looks-good' usertag.
Change-Id: I56630b15ec4fbc5c67e5420dbf2838556a005d6b
---
doc/contributing.texi | 53 +++++++++++++++++++++++++++++++++++++++----
1 file changed, 48 insertions(+), 5 deletions(-)
diff --git a/doc/contributing.texi b/doc/contributing.texi
index 864190b119..b09e9cc299 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.
@@ -605,7 +606,7 @@ Packaging Guidelines
* Version Numbers:: When the name is not enough.
* Synopses and Descriptions:: Helping users find the right package.
* Snippets versus Phases:: Whether to use a snippet, or a build phase.
-* Cyclic Module Dependencies:: Going full circle.
+* Cyclic Module Dependencies:: Going full circle.
* Emacs Packages:: Your Elisp fix.
* Python Modules:: A touch of British comedy.
* Perl Modules:: Little pearls.
@@ -1972,7 +1973,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}
@@ -1985,9 +1991,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
@@ -2005,6 +2011,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
@@ -2237,6 +2246,40 @@ 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, building, linting and running other
+people's series and sharing your comments about your experience will
+give some confidence to committers that should result in the proposed
+change being merged faster.
+
+@cindex LGTM, Looks Good To Me
+@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. The following well understood/codified @acronym{LGTM,
+Looks Good To Me} phrases should be used to sign off as a reviewer,
+meaning you have reviewed the change and that it looks good to you:
+
+@enumerate
+@item
+If the @emph{whole} series (containing multiple commits) looks good to
+you, reply with a @samp{This series LGTM!} to the cover page if it has
+one, or to the last patch of the series otherwise.
+
+@item
+If you instead want to mark a @emph{single commit} as reviewed (but not
+the whole series), simply reply with @samp{LGTM!} to that commit
+message.
+@end enumerate
+
+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
base-commit: 619ff2fa1d5b60b5fe33216ca2d6219c04a5515b
--
2.41.0
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: [PATCH v3] doc: Add some guidelines for reviewing. |
|
Date: |
Tue, 07 Nov 2023 11:14:00 -0500 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hello,
Ludovic Courtès <ludo@gnu.org> writes:
> Hello,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> * 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
>
> Could you mention the b4 change in the commit log? Otherwise LGTM!
Done, thanks for the review.
>> +[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
>
> Really cool to have the b4 workflow documented and a default config in
> place!
Now we could document more extensively some successful workflows in the
Cookbook (Debbugs/Gnus-based, QA-based, b4-based, etc.) :-).
--
Thanks,
Maxim
--- End Message ---