all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: "Ludovic Courtès" <ludovic.courtes@inria.fr>
Cc: guix-devel@gnu.org
Subject: Re: Tricking peer review
Date: Tue, 19 Oct 2021 16:22:30 +0200	[thread overview]
Message-ID: <86k0i9drh5.fsf@gmail.com> (raw)
In-Reply-To: <87sfwx896z.fsf@inria.fr>

Hi Ludo,

On Tue, 19 Oct 2021 at 14:56, Ludovic Courtès <ludovic.courtes@inria.fr> wrote:
> zimoun <zimon.toutoune@gmail.com> skribis:
>
>> I agree with a minor comment.  From my opinion, not enough patches are
>> going via guix-patches and are pushed directly.
>>
>> For instance, the «Commit policy» section says «For patches that just
>> add a new package, and a simple one, it’s OK to commit, if you’re
>> confident (which means you successfully built it in a chroot setup, and
>> have done a reasonable copyright and license auditing).»
>>
>> And from my point of view, new packages should *always* go via
>> guix-patches, wait 15 days, then push if no remark.  It lets the time
>> for the community to chime in.  And if not, it just slows down for 2
>> weeks.
>
> Three comments: (1) two weeks for a trivial Python/R/C package (the
> “simple one” rule above) can be a lot, (2) committers are by definition
> trusted to not mess up and to clean up behind them, and (3) when a
> simple package is pushed there’s after-the-fact peer review in practice
> (sometimes I reply to guix-commits notifications, for example.)

While I agree for updates or various fixes, I disagree when adding new
packages.  I do not see what is so urgent, I mean, if it was so urgent,
why the package had not been added before?  Therefore, I disagree with
(1) when adding new packages.

About (2), yes I agree that committers are by definition trusted.  No
question here.  However, (a) more eyes prevent mistakes and (b) some
ramblings.

One question is “encouragement” for reviewing, somehow.  Asking for new
package additions to go via guix-patches is a call making kind of
equality between contributors.  As someone without commit access, I can
tell you that it is often demotivating to send a trivial addition, wait
forever, ping people (aside I know who I have to ping :-)).  Usually, it
means people are busy elsewhere, so I try to help to reduce the workload
by reviewing stuff or by doing bug triage.  However, in the same time, I
see committers push their own trivial additions.  It appears to me
“unfair”.  Why are committer’s trivial additions more “urgent” than
mine?

I do not blame anyone, obviously not! I just comment here from my side
the current process in order to improve it.

About (3), if peer review before pushing can be used, how is a
after-the-fact peer review a justification?  Mistakes happen and I am
fine with that.  And hopefully they can be fixed.  However, they remain
forever in the Git history tree – therefore, here we have avoidable
“tragic” commits.

(This tricking peer review is a corollary of a more general
rambling about review. :-))

> I think it’s about finding the right balance to be reasonably efficient
> while not compromising on quality.

I totally agree.  And I do not see nor understand where is the
inefficiency here when asking to go via guix-patches and wait two weeks
for adding a new package.

Could you provide one concrete example of an urgent trivial package
addition?


Cheers,
simon


  reply	other threads:[~2021-10-19 15:12 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-15 18:54 Tricking peer review Ludovic Courtès
2021-10-15 22:03 ` Liliana Marie Prikler
2021-10-15 22:28   ` Ryan Prior
2021-10-15 22:45     ` Liliana Marie Prikler
2021-10-15 22:59       ` Ryan Prior
2021-10-18  7:40     ` Ludovic Courtès
2021-10-18 19:56       ` Ryan Prior
2021-10-19  8:39       ` zimoun
2021-10-20 23:03         ` Leo Famulari
2021-10-21  8:14           ` zimoun
2021-10-15 23:13   ` Thiago Jung Bauermann
2021-10-18  7:47     ` Ludovic Courtès
2021-10-18  7:34   ` Ludovic Courtès
2021-10-19  8:36 ` zimoun
2021-10-19 12:56   ` Ludovic Courtès
2021-10-19 14:22     ` zimoun [this message]
2021-10-19 15:41       ` Incentives for review Ludovic Courtès
2021-10-19 16:56         ` zimoun
2021-10-19 19:14         ` Ricardo Wurmus
2021-10-19 19:34           ` Christine Lemmer-Webber
2021-10-19 19:50           ` Joshua Branson
2021-10-21 20:03           ` Ludovic Courtès
2021-10-20 21:37         ` Thiago Jung Bauermann
2021-10-21 13:38           ` Artem Chernyak
2021-10-22 20:03             ` Thiago Jung Bauermann
2021-10-23  1:43               ` Kyle Meyer
2021-10-23  3:42                 ` Thiago Jung Bauermann
2021-10-23  7:37                 ` zimoun
2021-10-23 16:18                   ` public-inbox/elfeed -> Maildir bridge (was: Incentives for review) Kyle Meyer
2021-10-24 12:18                   ` Jonathan McHugh
2021-10-21 16:06           ` Incentives for review Ricardo Wurmus
2021-10-21 16:32             ` zimoun
2021-10-22 20:06             ` Thiago Jung Bauermann
2021-10-21 15:07         ` Katherine Cox-Buday
2021-10-21 16:10           ` Ricardo Wurmus
2021-10-21 17:52             ` Katherine Cox-Buday
2021-10-21 18:21             ` Arun Isaac
2021-10-21 19:58               ` Ludovic Courtès
2021-10-21 21:42               ` Ricardo Wurmus
2021-10-22 10:48                 ` Arun Isaac
2021-10-22 11:21                   ` zimoun
2021-10-23  6:09                     ` Arun Isaac
2021-10-22 10:56                 ` Jonathan McHugh
2021-10-22  7:40               ` zimoun
2021-10-22 11:09                 ` Arun Isaac
2021-10-22  8:37               ` Jonathan McHugh
2021-10-22  9:15                 ` zimoun
2021-10-22 10:40                 ` Jonathan McHugh
2021-10-22 11:32                   ` zimoun
2021-10-21 21:18             ` Jonathan McHugh
2021-10-22 10:44               ` Arun Isaac
2021-10-22 11:06               ` Jonathan McHugh
2021-10-21 21:22           ` zimoun
2021-10-28 14:57             ` Katherine Cox-Buday
2021-10-21 17:51         ` Vagrant Cascadian
2021-10-24 11:47           ` Efraim Flashner
2021-10-20  8:22   ` Tricking peer review Giovanni Biscuolo
2021-10-20  9:10     ` zimoun
2021-10-20  8:29   ` patches for new packages proper workflow (Re: Tricking peer review) Giovanni Biscuolo
2021-10-20 23:09 ` Tricking peer review Leo Famulari
2021-10-21  7:12   ` Ludovic Courtès
2021-10-25 13:09 ` Christine Lemmer-Webber
2021-10-28  8:38   ` Ludovic Courtès

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=86k0i9drh5.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=ludovic.courtes@inria.fr \
    /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.