[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On commit access, patch review, and remaining healthy

From: Hartmut Goebel
Subject: Re: On commit access, patch review, and remaining healthy
Date: Mon, 20 Jun 2022 14:53:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0


here are my reasons for reviewing patches very very rarely-

Basically I share Brian Cully's experiences. I'm using Thunderbird for mail and my system is set up to emacs could send out mails.

I tried debbugs from time to time and for me it is disgusting:

 * too complicated to get to the list of patches or bugs ( I never can
   remember the many key-presses to perform) ,
 * I did not manage to apply patches from there (emacs would need to
   know where my guix development directory is - how can I tell it?)
 * commands withing debbugs feel complicated
 * if a ticket contains several updated patches, its very hard to find
   those relevant (one of the reasons of forges' success is that they
   present you the current state)
 * actually testing the patches required to apply the patches to my
   worktree - and chances are high 'git am' will fail with some
   conflict - chances raise extremely for old patches
 * Over all for me debbugs.el needs a much more "noops"-friendly interface

Regarding the actual review:

 * Yes, I miss a review guide-line
 * As Arun wrote: Guix has high quality standards. I feel uncomfortable
   with judging whether a summary or description is good enough. Also
   I'm not a native speaker and don't feel entitled to review English
   gramar and spelling.
 * I miss a way to contribute to a review but not actually approving
   it. (In git(lab,hub) I could add comments other reviewers and the
   submitter could resolve or give feedback. This allows me to focus on
   e.g. some parts, while someone else could review the summary and
 * I also miss automated tests. E.g. it dos not make sense to waste my
   time for running 'guix lint', as a automate could do this.

When agreeing to a patch:

 * I'd like to simply merge the patch without taking care abut whether
   the submitter has commit right. This saves time for the submitter.
   Sending "LGTM" is pleasant, anyhow wasting time. The reviewer needs
   to send a mail, the submitter needs to dig the branch, rebase it and
   push. If the reviewer already did merge it, he/she could push, too,
 * And for me as a submitter: I want my patches to be merged by the

Am 07.06.22 um 17:11 schrieb Ludovic Courtès:
Do you or would you use them to keep track of pending patches?

I use eventually. Anyhow this is browse-only. I did not even manage to add a reply there.

Hartmut Goebel

| Hartmut Goebel          |                |
|  | compilers which you thought are impossible |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]