[TOPIC 04/11] Platform Support Policy

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.