On Wed, Jan 10, 2024 at 3:52 PM <rsbecker@xxxxxxxxxxxxx> wrote: > > On Wednesday, January 10, 2024 5:26 PM, Taylor Blau wrote: > >On Wed, Jan 10, 2024 at 05:15:53PM -0500, rsbecker@xxxxxxxxxxxxx wrote: > >> Just a brief concern: Rust is not broadly portable. Adding another > >> dependency to git will remove many existing platforms from future releases. > >> Please consider this carefully before going down this path. > > > >I was hoping to hear from you as one of the few (only?) folks who participate on > >the list and represent HPE NonStop users. > > > >I'm curious which if any of the compiler frontends that I listed in my earlier email > >would work for you. > > 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 ;) But, Randall's remarks bring up something pretty compelling: I don't think Git has a clearly defined platform support policy. As far as I can tell, the support policy now is "if you run `make test` on it and breaks, and you let us know, we'll try to fix it" - without much in the way of additional caveats. If I look in CodingGuidelines I see a few "this doesn't work on platform X so don't do it" (like around %z in printf), but nowhere do I see "how to know if your platform is supported" or even "here are platforms we have heard Git works OK on". That causes a lot of confusion for the project - threads like this one (and presumably a similar one about C99 adoption) become a blend of "is this change good for the project or not?" and "will this change leave behind platform X?" that is difficult to pick apart. Does it make sense for us to formalize a support policy? For example, if we wanted to formalize the status quo, I could envision: """ Platform support: We make a best-effort attempt to solve any bugs reported to the list, regardless of platform. To prevent breakages in the first place, consider running Git's `make test` regularly on your platform and reporting the results to git@xxxxxxxxxxxxxxx; or, better yet, consider adding your platform to the GitHub Actions CI (configured in `.github/`). """ Or, if we wanted to be able to move very nimbly, we could imagine something much more restrictive (note that I'm not endorsing it, just illustrating): """ Platform support: Git is guaranteed to work well on Linux platforms using a kernel version that is less than 1 year old. Support for all other platforms is best-effort; when reporting a bug on another platform, you may need to patch the issue and verify your fix yourself. """ I suspect there's a happy medium in here somewhere - trying to fix (or avoid) an issue on a platform which the average developer cannot run tests on is not a recipe for a happy developer, and a general policy of "patches welcome" for anything but latest Linux is not a recipe for happy users. 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?) If we had clearer answers to these questions, it'd be much simpler to determine whether experimentation with Rust is possible or useful. Plus it would make developer lives easier, in general, to understand how much compatibility support work they're potentially signing up for when sending a change of any size. - Emily
