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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Oct 11, 2024, 18:09 UTC
Message-ID: <CAPig+cRmyZhq1qtomTFP7p7XMqrCP8-u7ah8D2+yUtrL880y7g@mail.gmail.com>
In-Reply-To: <20241011074022.GC18010@coredump.intra.peff.net>

On Fri, Oct 11, 2024 at 3:40 AM Jeff King <peff@peff.net> wrote:

Show 17 quoted lines

> On Thu, Oct 10, 2024 at 11:56:08PM +0000, brian m. carlson wrote:
> > This series updates our requirements for libcurl to 7.61.0 (the version
> > in RHEL 8) and for Perl to 5.26.0 (the version in 15.6).  I considered
> > the mainstream LTS versions of RHEL, Debian, Ubuntu, and SLES, but
> > omitted consideration of paid support extended LTS, since we cannot
> > expect Git developers to have to pay a large corporation lots of money
> > just to test functionality.  This is in conformance with our policy,
> > which states that versions must be "in line with the version used by
> > other long-term-support distributions", which does not include extended
> > LTS distributions.
>
> I don't have a strong opinion on the extended LTS issue. Like you, I
> don't really care about dealing with paid support. OTOH, I think in many
> cases there was little to no maintenance burden for these older
> versions, since we'd already done the work to #ifdef them. But I guess
> since you broke up the patches, they can always choose to revert or
> include what they want.

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.

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.

Finally, there clearly are real-world cases[2] which benefit from Git continuing to support older platforms; why should we abandon them intentionally? And why should we turn down[3] the periodic trivial patch[4] which trickles in to help people on older platforms?

[1]: https://lore.kernel.org/git/xmqq1q0mh9gn.fsf@gitster.g/ [2]: https://lore.kernel.org/git/CAOO-Oz0NUA-YeyFT1MJ=XKyLWJvQoFH1b-F0EFOzvy8iWka3KA@mail.gmail.com/ [3]: https://lore.kernel.org/git/ZwhMmGt0kZvaSzSL@tapette.crustytoothpaste.net/ [4]: https://lore.kernel.org/git/CAOO-Oz1KhFcyErVx1Qb142PtPJS=UpgSD-FacckqNS4_okAtFQ@mail.gmail.com/