On Fri, Oct 11, 2024 at 4:01 PM brian m. carlson
<sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
> 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.
This attitude feels backward to me. It says that simplifying life for
Git developers ("the few") is of paramount importance and that Git
developers shouldn't care about inflicting pain/difficulty upon Git
users ("the many"). This is especially disturbing considering the size
of the Git user base.
Instead, for every proposed change to Git, we should be asking
ourselves what possible positive and negative impacts the change will
have on *users*, and if the negatives outweigh the positives, then the
change should be considered with a very wary eye indeed.
> > 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.
I don't disagree with your opinions about security and that, in an
ideal world, businesses should take these concerns seriously and
should upgrade. However...
> 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.
In my experience, it is very rare for the non-technical people
responsible for allocating funds to be convinced that money/time
should be spent on upgrading *working* systems. There are always more
urgent tasks (in their minds) which take priority. So, while there may
not be a compelling reason in the ideal world to forego upgrading, the
real world works differently.
> 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.
Ditto what I said above about this attitude feeling backward.
Moreover, as mentioned previously, it is not *this* project's
responsibility to be forcing people to upgrade their insecure systems.
> 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.
"Assuming we do that" is the key phrase. There have been proponents
and opponents, but almost nothing convincing written in favor of
adopting Rust according to a (mostly) outsider's summary of the
discussion[1]. The only properly compelling point in favor of Rust
came from Elijah; all other arguments for Rust had the flavor of
someone evangelizing for his or her latest favorite language. We've
seen such evangelizing before: numerous times with people insisting
that Git needed to be rewritten in C++, and (somewhat) more recently
when Felipe insisted, not only that Ruby be accepted into the project,
but that parts of the project should be rewritten in Ruby. But mere
evangelizing is not convincing. (Elijah's support for Rust was more
compelling, not only because he was not evangelizing, but because, as
usual with him, he backed up his position with solid, well-reasoned
statements of experience directly applicable to the Git project.)
[1]: https://lore.kernel.org/git/CAPig+cQtxx=fQM2xHSt8AsxyWgjSiS9Kd5PtjA+jDoK5s9xh4A@xxxxxxxxxxxxxx/
