>lun. 21 juil. 2025 at 23:57, "nomike (they/them)" <nom...@nomike.com> wrote:

> Hi
>
> On 17.07.25 11:52, Cayetano Santos wrote:
>> So, ... what is the conclusion regarding approvals ?
>> Do we have a policy about this ? I feel like approved changes get
>> committers away from them, as there is no need for a review, already

> This is configured so that there always need to be two approvals, from
> the group of eligible approvers, to be able to merge the Request into
> the main branch. Everybody who has made a commit in the request is not
> able to approve.
>
> This ensures that there are always at 3 people who look at each
> change: The origial author and two reviewers.

This is great, but we need to consider that this effectively doubles the
workload of maintainers, which is IMMO the main bottleneck of Guix: we
have now a rising ratio of ~20% open pr since the codeberg era.

> So maybe something like this could be implemented for Guix:
>
> There is a group of people who can approve PRs and once a PR is
> approved from at least 2 of those, any of them could hit the merge
> button.
>
> Because it feels odd that people are allowed to review submitted PRs
> and act as the quality gate, but then have to rely on someone else to
> do the actual merge.
> But on the other hand, maybe with signed commits, there is no other
> way to do this ¯\_(ツ)_/¯?

Good idea.

So we have committers (=maintainers), groups members and regular users.
Those who are allowed to approve pr are maintainers and group members
(regular users too?).

Upon a pr, a number of approvals (not from any of the pr commit authors)
N is required. Once reached, any maintainer can merge. Direct merges are
to avoid, except in the case of simple changes in leaf (or with
dependent < M) packages.

Considering that the maintainer which merges will probably have a look
at the pr to, I’d tend to set N,M=1. In the (mid term) ideal case, N=2
(1 at least from the team to which the pr relates).

C.

ps. No idea about the lost merge button, and how it relates to signing changes.

Attachment: signature.asc
Description: PGP signature

Reply via email to