On Thursday, July 11, 2024 4:13 PM, Kyle Lippincott wrote: >On Thu, Jul 11, 2024 at 11:15 AM Emily Shaffer <nasamuffin@xxxxxxxxxx> wrote: >> >> On Tue, Jul 9, 2024 at 4:16 PM brian m. carlson >> <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: >> > >> > On 2024-07-09 at 22:50:42, Emily Shaffer wrote: >> > > Right now, this doc talks about "guarantees." I used that phrasing >> > > based on what I've observed to be an implicit expectation that we >> > > guarantee support; it could be this isn't actually a guarantee >> > > that the community is willing to make, so I am hoping we can discuss it and >come up with the right term. >> > >> > I think it might be helpful to look at what some other projects do. >> > Rust has a concept of tiered support, and it requires platforms to >> > have maintainers who will commit to support an OS. I don't think we >> > necessarily need to be so formal, but if nobody's stepping up to >> > monitor an OS or architecture, it may break at any time and we won't >> > be able to consider it when deciding on features we require from the >> > platform (such as Rust, C versions, or POSIX versions). >> >> It took me a little time to find it, so here's the link for others: >> https://doc.rust-lang.org/nightly/rustc/platform-support.html >> >> I do think it's interesting that while Rust splits their tiers based >> on how much of it will definitely work (definitely builds+tests, >> definitely builds, probably builds maybe), which is different from how >> I sliced it by time (works on release, works on stable, works on >> unstable). This kind of lines up with what you mentioned next about >> the tests (or some subset) working, which I hadn't considered, either. >> >> > >> > 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). >> >> I'm not sure which of these requirements we'd want to enumerate - but >> does it make sense to tack it onto the end of this doc? Something >> like: >> >> """ >> 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 >> ... >> """ > >My concern with actually listing what the minimum requirements are is that we >then need a process for raising the minimum requirements. For C specification, I can >see that rightfully being an involved conversation and achieving consensus that this >is the right time to do it. For things like library versions, I'm less comfortable with it >because if we have to raise the minimum bar for some urgent reason, there's the >potential for additional friction with these platforms claiming that we stated we'd >support them (ex: we say you need to be able to use libfoo v3.x.x (v4.x.x had some >breaking changes, but coexists with v3, so we just stuck with v3), and some security >fix that we need to receive only exists on the v4 version, so now we need to port to >using v4 so that we get the security fix). > >I think it's probably fine to list minimum requirements, as long as we have >something conveying "and possibly other criteria". I don't want this interpreted as a >"do this, and we will try hard to not break you", it should be interpreted as "if you >can't do at least this, we won't even look at patches/tests/CI to unbreak you/keep >you unbroken" I have similar concerns both in terms of compilers and libraries. I am maintaining two exotic platforms, NonStop x86 and ia64. The ia64 is going off support "soon". In x86, we have more recent tooling, but not everything. It is at an older POSIX level. However, getting libraries built is either going hat in hand to HPE asking for updates on libraries or porting them myself. This is hard because gcc is not available, nor is likely to ever be - so anything with gcc in the mandatory toolchain is out of the question. For ia64, it doesn't matter much, and freezing on 2.49, or slightly later than 2.50 is not a horrible decision. I do have to keep x86 alive for the foreseeable future. My only real time limit is getting a 64-bit time_t (not available yet) in a 64-bit git build (also not possible yet) - which really depends on 64-bit versions of dependencies from the vendor, which is not easy to make happen. So, time limits are a definite concern and policies on those are important to quantify. Fortunately, I am monitoring and building git frequently looking for trouble. I think that part is important for any exotic maintainer and probably should be officially quantified/sanctioned. > >> >> > >> > 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? >> >> (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.) >> >> > >> > > +Compatible on `next` >> > > +-------------------- >> > > + >> > > +To guarantee that `next` will work for your platform, avoiding >> > > +reactive debugging and fixing: >> > > + >> > > +* You should add a runner for your platform to the GitHub Actions CI suite. >> > > +This suite is run when any Git developer proposes a new patch, >> > > +and having a runner for your platform/configuration means every >> > > +developer will know if they break you, immediately. >> > >> > I think this is a particularly helpful approach. I understand the >> > Linux runners support nested virtualization, so it's possible to run >> > tests in a VM on a Linux runner on OSes that Actions doesn't >> > natively support. I do this for several of my Rust projects[0] on >> > FreeBSD and NetBSD, for example, and it should work on platforms >> > that support Vagrant and run on x86-64. >> > >> > That won't catch things like alignment problems which don't affect >> > x86-64, but it does catch a lot of general portability problems that >> > are OS-related. >> > >> > I'm in agreement with all of your suggestions, by the way, and I >> > appreciate you opening this discussion. >> > >> > [0] An example for the curious is muter: https://github.com/bk2204/muter. >> >> Neat :) >> >> > -- >> > brian m. carlson (they/them or he/him) Toronto, Ontario, CA >>
