Platform Support Policy
=======================
(moderator: Emily; notetaker: Calvin)
* Emily: if you want Git to support your platform, you have to provide
your tests (e.g. provide your own CI test runner)
* Should we be more explicit about, for example, the version of C
that one must support.
* Brian: less-common architectures (e.g. MIPS) sometimes can catch
problems (e.g. unaligned access) that are not a good practice anyway
* qemu based CI is so slow
* netbsd, openbsd, freebsd, probably solaris are up to date with
modern standards, probably supportable
* I'm more comfortable with "you have to have threading and POSIX
2008" than with "you have to provide a CI runner"
* Peff: I'm not sure what people have been counting on
* Do we have a way to find out what people are using?
* "Take a little risk, see who screams" has worked okay in the past
but takes a while
* Rust is probably a big change
* Patrick: keep in mind that we're at the core of the whole operating
system, part of the bootstrapping path
* Emily: yes and no - Git is not just the client, but Git is a
standard. You can use older versions of Git and clone things from
GitHub. If we still support the same protocols, I don't think
needing native git.git CLI support to run on your platform is as
compelling as new Git being able to support these older standards.
* brian: OpenBSD doesn't like the GPL, has a project for getting
trees called "got", it's in C and supportable. It can be a valid
bootstrapping tool.
* Patrick: The user experience there is a little closer to CVS. But
it's still an option.
* Jrnieder: looking from user perspective, Git is the tool people are
used to for day to day development
* Emily: There's a difference between using "a git" vs using the
latest version.
* Jnieder: telling users to use an older version might result in
users asking questions on the mailing list about those older
versions, it's also not free.
* Peff: to be fair, HP Nonstop support hasn't been a matter of
"please support me for free" - the maintainer there has been active
in helping test and debug things. The question here is not about
whether to continue that but rather about whether we're willing to
increase the platform dependencies when it breaks such a use case.
* Peff: Are we okay with dropping NO_PTHREADS support?
* Brian: POSIX 2008 shouldn't be that controversial. Neither C11
should be. We shouldn't take it too far like POSIX 2024, but we
have to set "some" standards.
* Emily: So next week when we come home we update the "minimum
requirements" on the mailing list, and everybody upvotes?
* Jonathan: we live in the real world - the spirit of "let's require
POSIX 2008" sounds right, but real-world considerations should
matter more than the exact text of the standard
* Peff: example: Android is missing pthread_setcanceltype, which
leads to Git on Android using NO_PTHREADS
* brian: it can be enough to pretend to support (compatibility shim)
* Calvin: is there a threshold % of users for "unimportant enough to
break"?
* Jrnieder: it depends on the platform. Do the requirements that a given
platform imposes push us in a good direction in general as a project?
* For example, Windows is a very non-POSIXy platform, but it has
nudged us toward thinking about subprocesses in a different way,
and I think that's been really healthy
* brian: As another example, Plan 9 is really difficult to support,
it won't pass the test suite
* z/OS patches originally came in and were gross. I saw a patch come
in recently that was more acceptable.
