Re: [PATCH] Documentation: add platform support policy

>
> On 2024-07-11 at 23:15:35, Emily Shaffer wrote:
> > On Thu, Jul 11, 2024 at 3:24 PM brian m. carlson
> > <sandals@crustytoothpaste.net> wrote:
> > > 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.

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

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