On 09.04.26 22:55, Andres Freund wrote:
> I'd be interested in feedback about how high folks value different aspects:
>
> 1) CI software can be self hosted
>
> E.g. to prevent at least the cfbot case from being unpredictably abandoned
> again.
>
>
> 2) CI software is open source
>
> E.g. out of a principled stance, or control concerns.
I think we should work toward that in the long run. Open-source
software should also have an open-source (and distributed, and
privacy-respecting, and reusable, etc.) development process.
In the short run, meaning something that is plausible to get ready
between now and June/July, using some stopgap from an existing
established provider (such as GH actions) would probably be better.
> 3) CI runs quickly
>
> This matters e.g. for accepting running in containers and whether it's
> crucial to be able to have our images with everything pre-installed.
>
>
> 4) CI tests as many operating systems as possible
>
> A lot of system just support linux, plenty support macos, some support
> windows. Barely any support anything beyond that.
>
>
> 5) CI can be enabled on one's own repositories
>
> Cfbot obviously allows everyone to test patches some way, but sending patch
> sets to the list just to get a CI run obviously gets noisy quite fast.
>
> There are plenty of open source CI solutions, but clearly it's not viable
> for everyone to set that up for themselves. Plenty providers do allow doing
> so, but the overlap of this, open source (2), multiple platforms (4) is
> small if it exists.
This is the most important one, for me.
I think it would be even more useful if one could run the whole thing,
or most of the thing, locally. I mean, I can run all kinds of VMs
locally, all the pieces of this already exist. But it needs some
integration to build the images locally, and then run the build and test
processes in this images. This wouldn't cover everything (e.g., can't
virtualize macOS unless on macOS, IIRC), but I shouldn't really need to
push my code half-way around the world just to do a build run on NetBSD.
This could be someone's $season of code project.
> 7) Provide CI compute for "well known contributors" for free in their own
> repositories
>
> An alternative to 6) - with some CI solutions - can be to add folks to some
> team that allows them to use community resources (which so far have been
> donated). The problem with that is that it's administratively annoying,
> because one does need to be careful, or CI will be used to do
> cryptocurrency mining or such within a few days.
In a way, well known contributors can fend for themselves. We want to
get as many new or occasional contributors to run this so that the
patches build and test successfully before anyone else has to look at them.
