On Mon, Jan 22, 2024 at 3:18 PM Emily Shaffer <nasamuffin@xxxxxxxxxx> wrote: > > On Wed, Jan 10, 2024 at 3:52 PM <rsbecker@xxxxxxxxxxxxx> wrote: > > [...] > > Unfortunately, none of the compiler frontends listed previously can be built for NonStop. These appear to all require gcc either directly or transitively, which cannot be ported to NonStop. I do not expect this to change any time soon - and is outside of my control anyway. An attempt was made to port Rust but it did not succeed primarily because of that dependency. Similarly, Golang is also not portable to NonStop because of architecture assumptions made by the Go team that cannot be satisfied on NonStop at this time. If some of the memory/pointer issues are the primary concern, c11 might be something acceptable with smart pointers. C17 will eventually be deployable, but is not available on most currently supported OS versions on the platform. > > I hope y'all don't mind me hijacking this part of the thread ;) Of course not. :-) [...] > Does it make sense for us to formalize a support policy? 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... [...] > I see a few axes we can play with: > * which architectures/kernels/OS (do we care about more than the > usual suspects of Linux/Mac/Windows // x86/amd/arm // > POSIX-compliant?) > * age of architectures/kernels (do we care to offer full support for > a 10 or 15 year old OS?) > * new feature compatibility guarantees vs. core > functionality/security fix guarantees (which do we really define > "support" as?) > * test provisioning (do we require a VM we can run CI on, or is a > report generated from a nightly build and mailed to the list OK?) > * test/breakage timing (should the above tests run on every commit to > 'next'? every merge to 'master'? every RC?) > * who provides the support (is it the patch author's responsibility > to fix late-breaking platform support bugs? is it the reporter's > responsibility? and especially, how does this interplay with test > provisioning and frequency above?) 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@xxxxxxxxx/ > If we had clearer answers to these questions, it'd be much simpler to > determine whether experimentation with Rust is possible or useful. How so?
