guix-patches
[Top][All Lists]
Advanced

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

[bug#38846] [PATCH 0/4] Move 'HACKING' to the manual, and a proposal for


From: Ludovic Courtès
Subject: [bug#38846] [PATCH 0/4] Move 'HACKING' to the manual, and a proposal for commit access
Date: Tue, 07 Jan 2020 12:17:31 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi!

zimoun <address@hidden> skribis:

> However, let point 2 minor weak points for further discussions:
>
>  a- if the number of committers with access is more or less fixed,
> then access could be transferred (less active, less time, less
> motivation, etc.);

Sure, we should (and do) remove people who “disappeared” or retired, and
of course welcome new people willing to participate.

>  and b- the bottleneck is the patch review (even if it should be
> improved in the future with the Guix Data Service).
> Well, a- is more about human relationship, hard to fix. However, we
> should work on b- but how? What does it mean "encourage patch review"?
> Candy or beer at Guix Days? ;-)

Heh.  :-)  This is the hard part for all free software projects.  As you
noticed, there’s no shortage of patches that have fallen through the
cracks, unfortunately.

The “encourage patch review” bit in this series, in my view, is to tell
newcomers that the deal is not just that they can push their own stuff
more quickly, but also that they can help others get their stuff in in
return.  It may sound obvious to some, but it’s probably better if
explicitly stated.  Also, perhaps we’ve had the problem where committers
did not feel “entitled” to review and push other people’s patches; this
paragraph is also a way to tell them that yes, they _are_ entitled to
that.

It won’t solve the problem overnight; offering a beverage at the Guix
Days won’t solve it either but it’s a good idea anyway.  :-)

Ludo’.





reply via email to

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