Thanks, those are very helpful links!

> I did not try to setup CI on gitlab. Using sr.ht <http://sr.ht> aka
> source hut one has
> to push a .build.yml file in the repository which is discovered by the
> platform
> which triggers a build when a push is done e.g.
> https://git.sr.ht/~amz3/azul/tree/master/.build.yml
> Here is also the output of the build https://builds.sr.ht/~amz3/job/55428

Great, this looks like a nearly optimal solution to me :) It could
hardly be easier.

If the CI job of an individual SRFI passes, we'd still have to think of
some way to aggregate all those valid SRFIs into one place. This could
be done if the CI job sends a notification to a webhook that collects
the new version of the SRFI.

Last time we discussed this, Arthur's preferred workflow would be just
to mass "git pull" all SRFI repos onto his personal computer and then
run a local script to generate a "srfi-all.tar.gz" with the newest
versions all of SRFIs. On GitHub the mass "git pull" takes about 1-3
minutes and apparently they allow you to do it (there may be some
throttling of the network traffic but no-one has yet been banned or
contacted over it).

> One thing to take into account when considering source hut as git hosting
> platform is that it doesn't support, as of yet, merge requests in the
> web interface.

OK, that's good to know. I don't know if we have a consensus about this.
Traditional SRFI workflow is largely email-based I guess.

> It doesn't have a web interface for doing review. sr.ht <http://sr.ht>
> is meant to be
> used with mail-based workflows and see https://git-send-email.io/
> To support that workflow it provides a mailing list feature
> https://lists.sr.ht/
> It also has bug tracker https://todo.sr.ht/

OK, also interesting :) I had no idea mail-based workflows are still so
popular, it makes sense.

>     Easiest would be if we can just put a file like `.travis.yml` in the
>     repo and then it would perform CI automatically
>
> That is how source hut works and that is how I think gitlab ci works too.

I just checked the GitLab tutorial:
<https://docs.gitlab.com/ee/ci/quick_start/>. You have to push a file
like that, and also configure a "runner" to run the file (from the
GitLab control panel - I don't know if this step can be skipped using an
API or organization-wide setting).

>     (or push a button in the repo settings - something like that).
>
> IIRC sr.ht <http://sr.ht> allows to trigger builds from the interface
> and prolly gitlab has
> the same feature.

Sounds good :)

>     The problem with Travis is, we'd first have to make each SRFI repo in
>     GitHub as we now do, and _also_ separately add that repo in the Travis
>     control panel.
>
> It is clear that travis is not the perfect solution.

Agreed, just the fact that CI and Git are in different places is a bit
of a complication, given how many repos we have.