[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 |
Hi,
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
description.)
* 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,
IMHO.
* And for me as a submitter: I want my patches to be merged by the
reviewer.
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 issues.guix.gnu.org eventually. Anyhow this is browse-only. I did
not even manage to add a reply there.
--
Regards
Hartmut Goebel
| Hartmut Goebel |h.goebel@crazy-compilers.com |
|www.crazy-compilers.com | compilers which you thought are impossible |
- On commit access, patch review, and remaining healthy, Ludovic Courtès, 2022/06/02
- Re: On commit access, patch review, and remaining healthy, Brian Cully, 2022/06/02
- Re: On commit access, patch review, and remaining healthy, Ludovic Courtès, 2022/06/03
- Re: On commit access, patch review, and remaining healthy, Ricardo Wurmus, 2022/06/03
- Re: On commit access, patch review, and remaining healthy, Efraim Flashner, 2022/06/07
- Re: On commit access, patch review, and remaining healthy, Ludovic Courtès, 2022/06/07
- Re: On commit access, patch review, and remaining healthy, Efraim Flashner, 2022/06/08
- Re: On commit access, patch review, and remaining healthy, Ludovic Courtès, 2022/06/08
- Re: On commit access, patch review, and remaining healthy,
Hartmut Goebel <=
- Re: On commit access, patch review, and remaining healthy, zimoun, 2022/06/21
- Re: On commit access, patch review, and remaining healthy, Munyoki Kilyungi, 2022/06/22
Re: On commit access, patch review, and remaining healthy, Pier-Hugues Pellerin, 2022/06/02
Re: On commit access, patch review, and remaining healthy, Luis Felipe, 2022/06/02
Re: On commit access, patch review, and remaining healthy, Arun Isaac, 2022/06/06