Subject: [bug#76503] Forges and automation

From: Ludovic Courtès <[email-masked]>
Date: Mon, 10 Mar 2025 23:44:29 +0100

Hello Konrad,

Konrad Hinsen <[email-masked]> skribis:

> Lack of automation: I haven't seen much discussion about this aspect so
> far. Automating what, for who? Who needs to be able to control and
> fine-tune automation? Who needs to understand what's happening?
> At what stages in onboarding does this matter?

This phrase refers to the bots and CI systems many developers have
become used to.

Here’s an example:

  https://gitlab.inria.fr/guix-hpc/guix-hpc/-/merge_requests/159

The build status of the packaging changes are reported in the
discussion; the GitLab pipeline goes green upon success.  (Romain is
working on that sort of feedback for Forgejo instances in Cuirass though
the basics are already in place as noted in the GCD.)

A “modern forge” isn’t necessary for this, as https://qa.guix.gnu.org
has shown.  But just like it’s easier to write and maintain a browser
written in Rust than one written in assembly, it’s easier to integrate
qa.guix, Cuirass, and similar tools with a forge than with email.

This workflow also eases onboarding: without knowing anything about the
project’s infra, the contributor gets feedback about their submission
right where they posted it.  And it works: no worries about MUAs
wrapping lines, patches as MIME attachments vs. email body, etc.

With that in place, it becomes possible to have an auto-update bot like
that of Nixpkgs:

  https://nix-community.github.io/nixpkgs-update/r-ryantm/#r-ryantm

… which creates pull requests for package updates:

  https://github.com/NixOS/nixpkgs/pulls/r-ryantm

… which are then built, with package maintainers being pinged upon
success.

Again this could be done over email or UUCP, but having the interface
and semantics of a forge makes those things easier.

Ludo’.