@civodul@picnoir FOD stands for fixed output derivations. IIUC what PicNoir is suggesting that guix should use the lockfile of the Go/Rust package to define an intermediate package that contains all the dependencies for a package. This leads to less conflicts trying to find common versions that work for multiple crates at the expense of more storage requirements and longer build times
@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
@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.
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 # 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.
@civodul Has #guix considered moving of Savannah to sourcehut? One area that #guix is in a good position to improve self-hosting/autonomy/descentralization is by reducing the LoE to self host your forge.