Re: [PATCH 00/13] Update versions of libcurl and Perl

> On Fri, Oct 11, 2024 at 4:01 PM brian m. carlson
> <sandals@crustytoothpaste.net> 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.

> > 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.