On 2024-10-11 at 18:09:14, Eric Sunshine wrote: > I may be in the minority here, but I'm fairly negative on this entire > patch series. As you say, supporting these old versions is effectively > zero-cost, so how does this project benefit from these changes which > potentially "break" Git for users on older platforms? I see no upside > here. The cover letter provides no strong justification for > (potentially) inconveniencing people; the argument about being able to > utilize more modern Perl features is weak[1] at best and is not > convincing. It is not effectively zero cost. When I want to write a patch, I must make sure that it works on all the platforms we support, or my patch will get reverted or not picked up. That means I have to expend additional effort when adding features to look through the supported versions of our dependencies and either conditionally check them or skip the feature. Sometimes I have to rewrite that feature in a different way, or ship a compatibility stub for a system that doesn't support it. I have actually spent a decent amount of work getting things to work across older versions of software, both in Git and elsewhere. The more we honour the policy we have already made and agreed upon, the less work Git developers have to do to support adding and maintaining these features. I should be clear that I do very much value the portability of Git across systems and architectures: my first laptop was a PowerPC Mac running Linux and I've owned UltraSPARC, ARM64, and MIPS hardware. I really try to write code that doesn't have weird portability problems across architectures or OSes, and that's relatively easy to do. But I'm not willing to do lots of extra work to reimplement features or work around ancient systems because people can't upgrade their OS and dependencies. > Although brian is (quite rightly) concerned about security (or lack > thereof with older installations), it is not this project's > responsibility to "force" people to upgrade their insecure > installations. And it is not at all uncommon in the "Real World" for > decade-or-more old installations to be running in production > environments, and programmers need to work within those environments, > however, those installations are, for various business reasons (such > as cost-effectiveness and known stability), unlikely to (ever) be > upgraded to more modern versions. I, personally, deal with such > installations on a very regular basis, and in my experience, the only > time upgrades are undertaken (in production settings) is when the > systems break completely and there is no choice but to replace them. It isn't acceptable to run systems that don't have security updates applied that are connected to the Internet, period. In this day and age, it's very easy to have bugs in things like TLS or HTTP libraries that are written in C and have security-sensitive implications and that are exploitable remotely. No matter how stable your systems may be, it's very easy for unpatched systems to quickly become part of a botnet, which is a problem for everyone else. Typically most businesses that sell to other businesses have to be in compliance with certain security policies, especially if they have user or corporate data. My employer simply cannot refuse to upgrade because we risk major legal problems (e.g., GDPR or PIPEDA problems) or loss of most of our corporate customers because they won't or can't (due to regulatory requirements) do business with people who have lax security. So I very much doubt that there is, in the general case, any compelling business reason not to upgrade to a patched OS. Certainly we cannot force people to upgrade, but we also don't have to support those people. Git is an open-source project, and people are welcome to make changes that they want to it without our approval, as long as they comply with the license. I've worked at multiple companies where we had obsolete systems that needed to be upgraded but hadn't been and have dealt with that pain, including when it negatively affected us shipping Git. I still think that this is the appropriate policy to have. There's also discussion about adding Rust to Git. Assuming we do that, we're going to have to work with Rust's requirements for OSes, which usually follow major supported distros (for Linux) or upstream's policy (for the BSDs). So we're going to have the same problem in that people are actually going to have to upgrade to a supported OS, except it's really not going to be optional because the code simply won't compile. We might as well get used to doing that now. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
