Documentation: add platform support policy

Supporting many platforms is only easy when we have the right tools to
ensure that support.

Teach platform maintainers how they can help us to help them, by
explaining what kind of tooling support we would like to have, and what
level of support becomes available as a result. Provide examples so that
platform maintainers can see what we're asking for in practice.

With this policy in place, we can make changes with stronger assurance
that we are not breaking anybody we promised not to. Instead, we can
feel confident that our existing testing and integration practices
protect those who care from breakage.

Signed-off-by: Emily Shaffer <emilyshaffer@google.com>

---

New in v2:

- Added a "minimum requirements" list in response to brian and Kyle's
  suggestions. This doesn't mean "if you meet these requirements, we'll
  work hard to make sure Git works for you"; it means "if you don't meet
  these requirements, then your tests/runners/patches are not welcome."
  Would appreciate someone double-checking the language to make sure
  that's conveyed (nicely). Also, the list of requirements right now is
  very short, because I didn't want to make any assumptions :) so if
  there are more that I should add, please suggest them (or, maybe it
  makes more sense to suggest them as a follow-on patch).

- Added a section for a list of platform maintainers so we know who to
  contact. I guess this could probably use dates (although we have the
  `git blame`) to ensure that it's not too stale. I didn't add Dscho,
  because I figured we had better double-check with him before signing
  him up to anything; will add him to CC for this round. I didn't add
  avarab for AIX because the last I heard about it was years ago; will
  CC him too. Are there others that people know of?

- Fixed some typos Junio pointed out. I'm all thumbs.

- Reworded the "if we break release, we'll fix by next release" language
  to be less specific and hopefully more honest.

- Gave more detail about which branches are worth watching, and linked
  to the maintainer guide rather than the workflows guide. Also
  suggested watching `cabal`/security list.

- Made testing turnaround time requirement less specific (and more
  intimidating). Happy to hear suggestions for rephrasing, I'm worried
  it may be a little rude as is.

- Stopped mentioning coccicheck specifically; instead, invite people to
  discuss possible compatibility restrictions with the mailing list, as
  no one size fits all. I'd be happy to know if this is clear as written
  or not.

- Recommended tests restricting use of platform features come with an
  expiration date, and why. If I didn't get the reasoning right, please
  let me know and suggest a rephrase.

- Suggested that GitHub Actions aren't the only way to do on-demand CI,
  and if you come up with another way to do it that is as low-effort for
  developers, that's OK too.

Thanks,

 - Emily

v1 description at
https://lore.kernel.org/git/20240709225042.2005233-1-emilyshaffer@google.com/

Documentation/Makefile

@@ -118,6 +118,7 @@ TECH_DOCS += technical/multi-pack-index
 TECH_DOCS += technical/pack-heuristics
 TECH_DOCS += technical/parallel-checkout
 TECH_DOCS += technical/partial-clone
+TECH_DOCS += technical/platform-support
 TECH_DOCS += technical/racy-git
 TECH_DOCS += technical/reftable
 TECH_DOCS += technical/scalar

Documentation/technical/platform-support.txt

@@ -0,0 +1,138 @@
+Platform Support Policy
+=======================
+
+Git has a history of providing broad "support" for exotic platforms and older
+platforms, without an explicit commitment. This support becomes easier to
+maintain (and possible to commit to) when Git developers are provided with
+adequate tooling to test for compatibility. Various levels of tooling will
+allow us to make more solid commitments around Git's compatibility with your
+platform.
+
+Compatible by next release
+--------------------------
+
+To increase probability that compatibility issues introduced in a release
+will be fixed in a later release:
+
+* You should send a bug report as soon as you notice the breakage on your
+platform. The sooner you notice, the better; watching `seen` means you can
+notice problems before they are considered "done with review"; whereas watching
+`master` means the stable branch could break for your platform, but you have a
+decent chance of avoiding a tagged release breaking you. See "The Policy" in the
+link:../howto/maintain-git.txt[maintainer's guide] for an overview of which
+branches are used in git.git, and how.
+* The bug report should include information about what platform you are using.
+* You should also use linkgit:git-bisect[1] and determine which commit
+introduced the breakage.
+* Please include any information you have about the nature of the breakage: is
+it a memory alignment issue? Is an underlying library missing or broken for
+your platform? Is there some quirk about your platform which means typical
+practices (like malloc) behave strangely?
+* Once we begin to fix the issue, please work closely with the contributor
+working on it to test the proposed fix against your platform.
+
+Example: NonStop
+https://lore.kernel.org/git/01bd01da681a$b8d70a70$2a851f50$@nexbridge.com/[reports
+problems] when they're noticed.
+
+Compatible on `master` and point releases
+-----------------------------------------
+
+To guarantee that `master` and all point releases work for your platform the
+first time:
+
+* You should run nightly tests against the `next` branch and publish breakage
+reports to the mailing list immediately when they happen.
+** You may want to ask to join the mailto:git-security@googlegroups.com[security
+mailing list] in order to run tests against the fixes proposed there, too.
+* It may make sense to automate these; if you do, make sure they are not noisy
+(you don't need to send a report when everything works, only when something
+breaks).
+* Breakage reports should be actionable - include clear error messages that can
+help developers who may not have access to test directly on your platform.
+* You should use git-bisect and determine which commit introduced the breakage;
+if you can't do this with automation, you should do this yourself manually as
+soon as you notice a breakage report was sent.
+* You should either:
+** Provide VM access on-demand to a trusted developer working to fix the issue,
+so they can test their fix, OR
+** Work closely with the developer fixing the issue; the turnaround to check
+that their proposed fix works for your platform should be fast enough that it
+doesn't hinder the developer working on that fix. Slow testing turnarounds may
+cause the fix to miss the next release, or the developer may lose interest in
+working on the fix at all.
+
+Example:
+https://lore.kernel.org/git/CAHd-oW6X4cwD_yLNFONPnXXUAFPxgDoccv2SOdpeLrqmHCJB4Q@mail.gmail.com/[AIX]
+provides a build farm and runs tests against release candidates.
+
+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.
+** If adding it to GitHub Actions is infeasible (due to architecture constraints
+or for performance reasons), any other method which runs as automatically and
+quickly as possible works, too. For example, a service which snoops on the
+mailing list and automatically runs tests on new [PATCH] emails, replying to the
+author with the results, would also be within the spirit of this requirement.
+* If you rely on Git avoiding a specific pattern that doesn't work well with
+your platform (like a certain malloc pattern), raise it on the mailing list.
+There are a few ways to avoid these breakages, so we'll work case-by-case to
+find a solution that doesn't unnecessarily constrain other platforms to keep
+compatibility with yours.
+* If you rely on some configuration or behavior, add a test for it.  Untested
+behavior is subject to breakage at any time.
+** Clearly label these tests as necessary for platform compatibility. Add them
+to an isolated compatibility-related test suite, like a new t* file or unit test
+suite, so that they're easy to remove when compatibility is no longer required.
+If the specific compatibility need is gated behind an issue with another
+project, link to documentation of that issue (like a bug or email thread) to
+make it easier to tell when that compatibility need goes away.
+** Include a comment with an expiration date for these tests no more than 1 year
+from now. You can update the expiration date if your platform still needs that
+assurance down the road, but we need to know you still care about that
+compatibility case and are working to make it unnecessary.
+
+Example: We run our
+https://git.kernel.org/pub/scm/git/git.git/tree/.github/workflows/main.yml[CI
+suite] on Windows, Ubuntu, Mac, and others.
+
+Getting help writing platform support patches
+---------------------------------------------
+
+In general, when sending patches to fix platform support problems, follow
+these guidelines to make sure the patch is reviewed with the appropriate level
+of urgency:
+
+* Clearly state in the commit message that you are fixing a platform breakage,
+and for which platform.
+* Use the CI and test suite to ensure that the fix for your platform doesn't
+break other platforms.
+* If possible, add a test ensuring this regression doesn't happen again. If
+it's not possible to add a test, explain why in the commit message.
+
+Minimum Requirements
+--------------------
+
+Even if platform maintainers are willing to add tests or CI runners, we will
+not consider helping to support platforms that do not meet these minimum
+requirements:
+
+* Has C99 or C11
+* Has dependencies which were released in the past 10 years
+* Has active security support (taking security releases of dependencies, etc)
+
+Platform Maintainers
+--------------------
+
+If you maintain a platform, or Git for that platform, and intend to work with
+the Git project to ensure compatibility, please send a patch to add yourself to
+this list.
+
+NonStop: Randall S. Becker <rsbecker@nexbridge.com>