On Tue, Jul 9, 2024 at 4:16 PM brian m. carlson
[off-list ref] wrote:

On 2024-07-09 at 22:50:42, Emily Shaffer wrote:

quoted

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

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

quoted

+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