@civodul # Merging _your own_ changes requires you to look at other people submissions
This is a consequence of integration being the responsibility of the CI. #nixpkgs maintainers have to go through the same process as non-maintainers. They can't push to master. If #guix maintainers had to visit https://issues.guix.gnu.org/ my guess is that there would be more eyes on other people submissions.
To merge a change in nixpkgs one needs to press a button. For guix one needs to download the patch locally, rebuild to double check and then push. The extra steps can be done by a CI, it doesn't require a pull request flow.
@civodul # Automated 'first response' triaging of a submission
This includes adding a reviewer automatically. You don't even have to have a commit bit to be able to approve the change. This is important because it lets the submitter know that who is they need to reach out in case their change is forgotten. It also lets maintainers check their 'backlog' of submissions.
@civodul ah, that is true. But one still doesnt have to open issues.guix to submit a patch. So there is less 'foot traffic' from maintainers. That said, I reducing the amount of human work needed to integrate a change is something that would be more impactful. Ie. if one can could tell cuirasa to merge a change to master by sending a message/command/tag
@PuercoPop Agreed, though there’s also the fact that every commit must be signed by an authorized committer: this is how users authenticate what ‘guix pull’ gives us and a key security aspect.
The unfortunate side effect (or not so unfortunate, depending on how one looks at it) is that this rules out automated commits.