On 2025-07-17 at 20:32:17, Ezekiel Newren via GitGitGadget wrote: > This series accelerates xdiff by 5-19%. That's great. > It also introduces Rust as a hard dependency. I think that's fine. We already discussed doing this at the last Contributor Summit in Berlin and everyone was in favour. While we did not have every contributor represented, I think that unanimity of the contributors present is a compelling enough reason. > …and it doesn’t yet pass a couple of the github workflows; hints from > Windows experts, and opinions on ambiguous primitives would be appreciated > (see below). > > This is just the beginning of many patches that I have to convert portions > of, maybe eventually all of, xdiff to Rust. While working on that > conversion, I found several ways to clarify the code, along with some > optimizations. > > So... > > This obviously raises the question of whether we are ready to accept a hard > dependency on Rust. Previous discussions on the mailing list and at Git > Merge 2024 have not answered that question. If not now, will we be willing > to accept such a hard dependency later? And what route do we want to take to > get there? Again, I think that's fine. I have a proposed policy at [0] (available from the `rust` branch on that remote). Included in that policy is a link to [1], which I summarize as "the U.S. government is proposing to classify development in memory unsafe languages as a Product Security Bad Practice." The proposal is that a memory safety roadmap be introduced by the end of 2025. Now, do let me be clear that I don't agree with everything that the U.S. government says or does (far from it), but I do think this is a sensible proposal (or I wouldn't have cited it) and it will be showing up in a lot more security standards coming down the line, especially for those forges and companies which will be selling to governments around the world. There's no time like the present to do this. I realize that that means that we will lose support for some platforms. I ultimately think that it's up to the porters and maintainers for a platform to maintain appropriate toolchains on that platform and that, while we should be cognizant of the requirements for adding new platforms or architectures, that shouldn't prevent the inclusion of important new tools like memory-safe languages. I would like to see a change to our platform policy and a policy on Rust before we merge this. I know your series adds support for 1.87, but because distros don't run the latest toolchain, we had discussed in the past targeting Debian stable's version plus an additional year after the new release. This means we'll support a Rust version for three years, which is a reasonable amount of time for a toolchain and allows distros to easily backport security fixes. If you would like, you are welcome to use my proposed policy as a basis for this, or I can send that out as a separate document if you don't want to write one or revise mine. [0] https://github.com/bk2204/git/commit/fbeb1180c7473635a964daed2da642c53487782d [1] https://www.cisa.gov/resources-tools/resources/product-security-bad-practices -- brian m. carlson (they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
