From: "Clément Lassieur" <clement@lassieur.org>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: 66436@debbugs.gnu.org, "Ludovic Courtès" <ludo@gnu.org>
Subject: [bug#66436] [PATCH v2] doc: Add some guidelines for reviewing.
Date: Sun, 22 Oct 2023 22:03:12 +0200 [thread overview]
Message-ID: <87il6ybf27.fsf@lassieur.org> (raw)
In-Reply-To: <87r0logap6.fsf@gmail.com> (Maxim Cournoyer's message of "Fri, 20 Oct 2023 19:01:41 -0400")
Hi Maxim,
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>> 1. What should the reviewer do with old-style patches, like the ones
>> that don't use G-Expressions? Should we tell the submitter to use
>> them when possible or is it only a matter of style that is up to the
>> submitter? Obviously they are hard to grasp for newcomers.
>>
>> It's probably good for newcomers if we teach them how to use
>> G-Expressions but we don't really have time to do so, given the
>> number of patches waiting to be reviewed.
>>
>> This question could be extended to style issues. Like using %var
>> versus var.
>
> I think we should now make sure all new submissions use the current
> style; if they aren't we can demand of the contributors to adjust it.
> There is a blog post and enough examples in the code base already that
> should make this not too difficult.
Are you referring to this one?
https://guix.gnu.org/en/blog/2023/dissecting-guix-part-3-g-expressions/
>> 2. What should the reviewer do when only small changes are required?
>> The reviewer could do these changes in seconds whereas asking for a
>> new revision could take days. These changes could be indentation
>> fixes, removing of unused code, but they could also be more
>> substantial, like adding a missing `file-name` field. Or changing
>> old-style to G-Expressions?
>>
>> If the reviewer makes such changes and pushes them right away, I
>> imagine they should be documented and explained.
>
> +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, and should result in
> +the proposed change being merged faster.
>
> So it does mention trying out the software ("running").
Yes indeed! I didn't see it.
Thanks for your reply!
Clément
next prev parent reply other threads:[~2023-10-22 20:05 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 [this message]
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 ` [bug#66436] [PATCH v3] doc: Add some guidelines for reviewing Maxim Cournoyer
2023-11-05 14:51 ` 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=87il6ybf27.fsf@lassieur.org \
--to=clement@lassieur.org \
--cc=66436@debbugs.gnu.org \
--cc=ludo@gnu.org \
--cc=maxim.cournoyer@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.