On Fri, Jul 12, 2024 at 12:33 PM brian m. carlson
[off-list ref] wrote:

On 2024-07-11 at 23:15:35, Emily Shaffer wrote:

quoted

On Thu, Jul 11, 2024 at 3:24 PM brian m. carlson
[off-list ref] wrote:

quoted

Some older OSes require kernel features that aren't compiled in by
default, so containers are out.  For example, CentOS 6 won't run on a
modern kernel because it lacks whatever the predecessor to the vDSO was
(which can be recompiled into the kernel, but nobody does that).

Is this hinting that we should mention a minimum kernel version for
Linux-kernel-based OSes?

This is actually a feature that still exists in the kernel and could be
enabled for newer kernels, but because distros don't use it (they use
the vDSO instead), they don't compile it in.

I'm not sure a minimum kernel version is helpful, because most of the
LTS distro kernels backport features, like Red Hat backported getrandom
for example.  In the interests of getting to a useful agreement, I think
for now we should just punt on this and having a 10 year lifespan will
probably do the trick, and we can determine in the future if we need to
apply more stringent measures.

Sounds good, thanks!

quoted

quoted

We also don't really want to be on the hook for trying to support OSes
Ubuntu is still derived from Debian.  It is likely that things which
work in one will work in another, but not guaranteed.

I mention Debian is because it has a large variety of supported
architectures.  I absolutely don't want to say, "Oh, you have MIPS
hardware, too bad if Git doesn't work for you."  (I assure you the
distro maintainers will be displeased if we break Git on less common
architectures, as will I.)  In fact, MIPS is an architecture that
requires natural alignment and can be big-endian, so it's very useful in
helping us find places we wrote invalid or unportable C.

The reason I'm very hesitant to require that we run everything in GitHub
Actions because it only supports two architectures.  ARM64 and RISC-V
are really popular, and I can tell you that running even a Linux
container in emulation is really quite slow.  I do it for my projects,
but Git LFS only builds one set of non-x86 packages (the latest Debian)
because emulation is far too slow to build the normal suite of five or
six packages.

Does that restriction apply to just GitHub-hosted runners, though?
Would it be possible for an interested party to set up self-hosted
runners (configured via GH Actions) that are using AMD or POWER or
whatever? (For example, I think it would be quite feasible for Google
to donate some compute for this, though no promises).

Self-hosted runners on public code are very hard to secure.  You're
basically letting arbitrary people on the Internet run code on those
machines and make outgoing network connections (due to the fact that you
can push whatever into a PR branch), with all of the potential for abuse
that that involves (and as my colleagues can tell you, there's a whole
lot of it).  GitHub has taken extensive pains to secure GitHub Actions
runners in the cloud, and while we use self-hosted runners for some
internal projects, they are absolutely not allowed for any public
project for that reason.

I would be delighted if Google were willing to do that, but I think
you're going to need help from teams like Google Cloud who are going to
be used to dealing with abuse at scale, like cryptocurrency miners and
such.  Unfortunately, there are many people who act in a less than
lovely way and will exploit whatever they can to make a buck.

I will also note that the official Actions runner is in C# and only runs
on a handful of platforms due to the lack of portability of C#.  (It
might theoretically run on Mono, which would increase its portability,
but I must profess my complete ignorance on anything about that code.) I
also know of an unofficial one in Go[0], which I'm for obvious reasons
unable to endorse, encourage, or speak about authoritatively in any way,
but that would still exclude some platforms and architectures which
don't support Go.

Do you think it's worth us linking out to some helpful doc (like the
official one, and someone who doesn't work at GH adding a link to some
unofficial Golang thing)? I sort of feel like since "you can also DIY
a scraper that looks at the mailing list if you want" is included, the
gist makes it across, so I'm tempted not to go into a bunch of
prescriptive detail here.

quoted

The appeal is not "because GitHub Actions are great!" for me - the
appeal is "because most Git developers run the CI this way if they
remember to or use GGG, and Junio runs it on `seen` all the time". If
there's some other recommendation for self-service CI runs that don't
need some careful reminding or secret knowledge to run, I'm happy with
that too. (For example, if someone wants to set up some bot that looks
for new [PATCH]-shaped emails, applies, builds, runs tests, and mails
test results to the author after run, that would fit into the spirit
of this point, although that sounds like a lot of setup to me.)

Yeah, I understand what you're going for.  If there were some super easy
way to get everything running in an automatic CI, I'm all for it.  I
think CI is the easiest way to make sure we don't break anything.

I think it's worth trying to get CI set up for whatever we can, and if
CI is a possibility somewhere, it becomes a lot easier to say yes.

quoted

Should have a reroll in the next 30min, it was ready to go and then I
got this mail :)

Sounds good.  I don't think anything in this email should affect that
reroll.

[0] https://github.com/ChristopherHX/github-act-runner
--
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA