On Tue, 11 Mar 2025 02:32:42 +0100 Denis 'GNUtoo' Carikli <gnu...@cyberdimension.org> wrote: > Another issue is that we'd probably need to tell contributors not to > expect reviews within the forge. It could be told inside the Guix > manual. And at the end of the day, if contributors don't understand > that, it will probably not increase the maintainers work anyway. I've looked at that, and the Libre En Communs instance of forgejo doesn't support that, but in another hand it's possible to disable the builtin bug reports for a given git repository and point to an external URL instead.
So this might be something that could be implemented for pull requests as well as they can be disabled and both settings are in the same page, so it would also make sense for consistency. Another way to get the information of the review within a common infrastructure would be be to somehow add an URL of the patch review within the patch that will go inside Guix and to build automatic tooling to somehow fetch the relevant discussion and integrate it in the guix patch mailing list (and deploy public-inbox) and/or in a git repository. This could improve the ability to search bugs offline and/or make it easier to integrate in workflows. Though we'd probably loose the ability to search contributions that didn't make it in Guix, and that could be relevant for people that need to be evaluated for commit access, but for the rest, information on what is not yet in Guix is probably not really needed for the maintenance of what made it in Guix. In the later case it also enables to selectively migrate teams to forges, depending on what each team prefer and still have a common place to find the discussions. Both ideas could also be mixed and matched depending on what individual team prefer. Denis.
pgpMSofCDgG80.pgp
Description: OpenPGP digital signature
