On 2024-07-11 at 18:14:36, Emily Shaffer wrote: > On Tue, Jul 9, 2024 at 4:16 PM brian m. carlson > <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > I think it's also worth discussing what we require from a platform we're > > willing to support. For example, we might require that the platform > > pass the entire testsuite (ignoring irrelevant tests or tests for things > > that platform doesn't use, such as Perl) or be actively pursuing an > > attempt to do so. We may also want to require that an OS be actively > > receiving security support so that we don't have people asking us to > > carry patches for actively obsolete OSes, such as CentOS 6. Finally, > > some sort of time limit may be helpful, since some Linux vendors are now > > offering 15 years of support, and we really may not want to target > > really ancient versions of things like libcurl. > > I sort of wonder how much of this is taken care of by expressing > "fully supported" as "can run in GitHub Actions". Even if an LTS > distro is 12 years old and using ancient curl, will GitHub still be > able to run it in a VM/container? Maybe there's no such guarantee, > since you can hook up self-hosted runners (which sounds more appealing > if someone's got something weird enough it doesn't run well in a > container). 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). We also don't really want to be on the hook for trying to support OSes that get no security support. We don't want to be running an OS connected to the Internet that has known root security holes, even in a CI environment, so I think _someone_ should be providing security support for it to their customers or the public free of charge. I also want to let us use new features from time to time that may not be able to be conditionally compiled in (such as new Perl features), so I think maybe setting a hard limit on a supported age of software might be a good idea. If we want to have good support for LTS Linux distros, we could set it at 10 years initially. Also, if we do decide to adopt Rust in the future, we'll need to consider a different lifetime policy for that. I try to support an old Debian release for a year after the new one comes out, which is about three years for a compiler version, but anything older that that becomes a real bear to support because most dependencies won't support older versions. Since we're not using Rust now, we don't have to consider that at the moment, but it's a thing to think about when we're discussing policy since different language communities have different expectations. We might find that we need different policies for, say, Perl than we do for C. > """ > Minimum Requirements > ------ > > Even if tests or CI runners are added to guarantee support, supported > platforms must: > > * Be compatible with C99 > * Use curl vX.Y.Z or later > * Use zlib vA.B.C or later > ... > """ I think to start off, we could say that it has to have C99 or C11, that dependencies must have been released upstream in the past 10 years, and that the platform and dependencies must have security support. I mention C99 or C11 because Windows _does_ have C11 but not C99; they are mostly compatible, but not entirely. FreeBSD also _requires_ C11 for its header files and won't compile with C99. I think the difference is small enough that we can paper over it ourselves with little difficulty, though. > > At the same time, we do have people actively building Git on a variety > > of platforms and a huge number of architectures, including most Linux > > distros and the BSDs, and we will want to be cognizant that we should > > avoid breaking those environments when possible, even though, say, the > > porters for some of those OSes or architectures may not actively follow > > the list (due to limited porters and lots of porting work). I imagine > > we might say that released architectures on certain distros (Debian > > comes to mind as a very portable option) might be implicitly supported. > > Are they implicitly supported, or are they explicitly supported via > the GH runners? Or indirectly supported? For example, the Actions > suite tests on Ubuntu; at least once upon a time Ubuntu was derived > from Debian (is it still? I don't play with distros much anymore); so > would that mean that running tests in Ubuntu also implies they will > pass in Debian? 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. And it's actually much easier to run Linux binaries in emulation in a container because QEMU supports that natively. Most other OSes must run a full OS in emulation, which is slower. There also aren't usually pre-made images for that; I tend to use Vagrant, which has pre-built images for x86-64, but I don't really want to be bootstrapping OS images other architectures in CI. So I'd say that we might want to consider supporting all release architectures on specific OSes. I think Debian is one of the more portable Linux distros (more portable than Ubuntu). Debian has also abandoned some architectures that you can't buy anymore, like Itanium, so that might be a reasonable limit on how far we're willing to go. > (By the way, I think we should probably just add a BSD test runner to > Actions config; we test on MacOS but that's not that closely related. > It seems like it might be a pretty easy lift to do that.) FreeBSD and NetBSD are pretty easy. I won't 100% commit to it, but if I find time I'll try to send a patch. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
