On Monday, July 15, 2024 6:28 PM, Emily Shaffer wrote: >On Fri, Jul 12, 2024 at 12:46 PM <rsbecker@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> 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 >>
