The goal is to provide an “almost stateless” forge featuring things like continuation integration, using existing tools (Laminar, cgit, etc.), so users can take control of their development. Insightful!
Is there a discussion somewhere on Laminar vs Jenkins or other popular floss CI programs?
@civodul, how easy would it be to integrate the mailing list with CI, Laminar in this case or any other? Guix development is employing debbugs and a specific CI but AFAICT they are not integrated? A glance at Laminar it seems that it would be possible if public-inbox (or another mailing list) provides a hook, but does the CI system employ any sandboxxing?
@cnx Right, guix-forge makes choices different from those the Guix project makes.
There are currently services for almost all the infrastructure Guix uses: mumi (for issues.guix.gnu.org), Cuirass (continuous integration), etc. But those are currently not provided by guix-forge.
@civodul, I am more interested in if there’s any working solution other than SourceHut for CI triggered by email patches. (I’m eyeing to host SourceHut at the moment, but still want to know all the options.)
So, does mumi+Cuirass integrate such feature and will it possible for guix-forge to be?
@cnx Not really, but @cbaines did a lot of work integrating Patchwork (which takes care of extracting patches from free-form email) and the Guix Data Service + Guix Build Coordinator. I’m not sure if this can easily be deployed from Guix System.
I hear that b4 + public-inbox also does part of that work.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!