RE: [PATCH] Documentation: add platform support policy

[<rsbecker@nexbridge.com>]

On Monday, July 15, 2024 6:28 PM, Emily Shaffer wrote:
>On Fri, Jul 12, 2024 at 12:46 PM <rsbecker@nexbridge.com> wrote:
>>
>> On Friday, July 12, 2024 3:34 PM, brian m. carlson wrote:
>> >Subject: 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.
>>
>> 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.
>>
>> >> > 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'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.

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

>> >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.
>>
>> We don't have C# or Go, nor are likely to any time soon, so that is a problem.
>>
>> >
>> >> 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
>>
>> --Randall
>>