guix-devel
[Top][All Lists]
Advanced

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

Re: Tricking peer review


From: zimoun
Subject: Re: Tricking peer review
Date: Tue, 19 Oct 2021 16:22:30 +0200

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 via email to

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