>dim. 06 juil. 2025 at 16:34, Andreas Enge <andr...@enge.fr> wrote:

> Hello,
>
> another question of policy and convention.
>
> I have recently been surprised by committers approving pull requests,
> wondering why they did not instead push them themselves. It might make
> sense when reacting to other committers (we never discussed whether it
> would be more polite to let committers push their own commits, or okay
> to push on their behalf), but it feels counterproductive with
> non-committers.

The issue gets more tricky when you consider that pr are mostly reviewed
by team members, and some teams are rather thin. If one of them submits
and the second approves, who commits the changes ?

> When I recently came across such a PR, I ended up spending time looking
> at it again - having someone else approve it gave me confidence and I
> was probably a bit faster, but since I was taking responsibility by
> being the one signing the commit, I also did not want to push it
> blindly. So instead of just one committer spending time on this PR,
> we ended up being two.

I fully agree: this doubles the amount of work to do, which is historically
the bottleneck we have in Guix. At the same time, this is an assurance
of quality, by effectively doubling the review process.

> So how should we proceed?

As we are probably not the first group to afford this kind of debate,
maybe an overview of current policies in other projects is a good idea.

> You probably guess from the above that I think that committers should
> not approve, but commit instead.
> And when I think about it, committers should also push (and sign) other
> committers' PRs.
>
> What do you think?

Check out the history of commits in the codeberg era: for a low ratio
of regular committers / pr, let’s not overcharge them; if this number
increases, adopt some kind of policy where before committing, someone’s
else must have approved the changes before.

--
Cayetano Santos
.
gpg: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682
key: meta.sr.ht/~csantosb.pgp

Attachment: signature.asc
Description: PGP signature

Reply via email to