Re: Defining a platform support policy (Was: [DISCUSS] Introducing Rust into the Git project)

On Mon, Jan 22, 2024 at 3:18 PM Emily Shaffer <nasamuffin@google.com> wrote:

[...]

Of course not.  :-)

[...]

Some hurdles that may need to be overcome if we want to do so:

* For a significant number of the discussions I remember, a
significant challenge was that we don't even know which platforms Git
is used on.  That's why we sometimes agree to weather balloon patches
that attempt to use some new option, in a way that is really easy to
remove...and if no one complains for a long enough time, then we
presume all platforms support it and start adding hard dependencies on
it.
* We are often happy to try to fix issues on even obscure platforms if
we get a detailed enough description showing exactly what the problem
is
* However, when reports don't come with a complete diagnosis, we often
will tell people who are reporting issues that we don't have access to
such a platform and someone else will have to dig further.  This
happens more often for exotic platforms (AIX, NonStop, etc.) but also
happens with mainstream platforms (Mac, Windows, and I think I've even
seen it happen with Linux).
* Even when folks report that they can't help the reporter, the work
doesn't always go back to the reporter, because someone else on the
list may respond and dig in; that happens more for mainstream
platforms but can happen with the exotic platforms as well.
* How exactly can we even enforce continued platform support?  What's
the actual mechanism?  I think the only route available to us is
people who care and try to provide reports, testing, patches, new
tools (e.g. our CI runs and gitgitgadget providing reports across
several of the more common platforms, with lots of work to investigate
the occasional weird build issues and flakes so it continues to be
fairly reliable), but what happens if some of those developers start
caring less...and yet we still have an encoded policy that their
platforms are supported?

I generally think we value portability fairly highly, but it clearly has bounds...fuzzy and even unknown-by-us bounds. I don't know how to translate that into a policy, and I'm curious if trying to apply nice sharp boundaries risks unreasonable expectations on either or both sides.

Also...

[...]

That's a great list of questions, but to me it does seem to lean towards "whatever is supported is supported equally". I don't know if that was intended, or just the way I read it. But if it was intended, I'd say that while equal support may be an ideal, I suspect it is pragmatically just too expensive as evidenced by the many optional features we already have, many (all?) of which have roots in platform support or the lack thereof:

  * gitk (NO_TCLTK)
  * dumb http(s) transport (NO_EXPAT)
  * smart http(s) transport (NO_CURL)
  * perl regexes (USE_LIBPRCRE)
  * translations (NO_GETTEXT)
  * charset conversions (NO_ICONV)
  * p4 support (NO_PYTHON, affected other scripts in the past too)
  * svn, send-email, gitweb support (NO_PERL, affected other stuff in
the past too)
  * fsmonitor (FSMONITOR_DAEMON_BACKEND)

Also, this list isn't just an "exotic" vs. "mainstream" platform thing, since even Linux is "second class" in the final category[1].

So, I think if we create a "supported platforms" policy, it should address optional features as well (though perhaps as simply as "the support policy only applies to non-optional parts of Git").

[1] https://lore.kernel.org/git/pull.1352.v5.git.git.1670882286.gitgitgadget@gmail.com/

How so?