GNU bug report logs - #66436
[PATCH] doc: Add some guidelines for reviewing.

Previous Next

Full log

Message #56 received at 66436 <at> debbugs.gnu.org (full text, mbox):

From: Clément Lassieur <clement <at> lassieur.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 66436 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: [bug#66436] [PATCH v2] doc: Add some guidelines for reviewing.
Date: Sun, 22 Oct 2023 22:03:12 +0200

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.