On Monday, July 15, 2024 6:28 PM, Emily Shaffer wrote:

On Fri, Jul 12, 2024 at 12:46 PM [off-list ref] wrote:

quoted

On Friday, July 12, 2024 3:34 PM, brian m. carlson wrote:

quoted

Subject: Re: [PATCH] Documentation: add platform support policy

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).

quoted

quoted

quoted

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.

quoted

When looking at the "exotics", many have their own kernel lifespans. When

worrying about NonStop, for example, the Kernel version stays around about 5
years under full support, then goes another few until retired. I think it is important
for people to know the compatible versions of the kernel builds have. I do track
those for the platform.

quoted

quoted

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.

quoted

quoted

quoted

quoted

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.

quoted

I'm not sure this applies to some of the exotics. NonStop cannot run the Google CI

code.


I assume you meant the GitHub CI code?

Yes, sorry.

quoted

While we could, in theory, connect to via SSH to run builds, my system is behind a

VPN/Firewall, which would make the builds impossible. I do build using Jenkins
based on an SCM poll. It's not perfect and some tests do not run correctly in Jenkins
but do outside. I would like to provide the feedback to the git team, somehow, on
what built successfully or not, outside of the mailing list.

I hope that the overall intent - you need to give us *something* that we can self-
serve issue reproduction on, or else you can deal with lower quality of service - is
clear and understood. It sounds like this puts NonStop squarely into this second
category, running against `next` or `seen` on a nightly cadence and publishing
breakage reports, then working closely with developers to make fixes as appropriate
(or making them yourself). (By the way, is this doc something you can point your
manager chain to to explain why Git issues appear and how to stop them from
doing so? Maybe that would make your life easier, even if the answer to that
conversation is "we can't provide what Git is asking for, so we'll be OK with lower
quality of support"...)

That is my expectation also.

quoted

quoted

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.

quoted

We don't have C# or Go, nor are likely to any time soon, so that is a problem.

quoted

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

--Randall