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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Oct 22, 2024, 21:58 UTC
Message-ID: <ZxggIfymo78PhXrz@tapette.crustytoothpaste.net>
In-Reply-To: <66bb101c-eb9f-4824-8766-750e58cd422e@gentoo.org>

On 2024-10-22 at 03:34:25, Eli Schwartz wrote:

Show 11 quoted lines

> Your general observation about respecting the platform support policy
> and not making developers expend time working around ancient dependency
> versions no one should be using... is something that I would say is a
> better fit for, well, the platform support policy.
> 
> You could instead add a section to the platform support policy detailing
> the minimum versions of dependencies which the git developers are
> willing to spend time supporting. A developer working on changes which
> would be onerous to backfill support for, would then have a simple,
> documented, easy to find policy about when it is acceptable to bump the
> version documented in ./INSTALL. The process would then look like:

We already wrote this out. If it's supported in a major LTS (not extended LTS) distribution, then we support it; otherwise, we don't. I plan to add some specific CI jobs to cover common supported platforms in the future, so we actually test what we're supporting.

Show 14 quoted lines

> - Code a new feature.
> 
> - Check the version table to see if maybe it was added basically
>   yesterday in curl 8.7, or whether it is available in say, curl 7.75.
> 
> - Discover it was added in curl 7.59. Oh shoot! The ./INSTALL says we
>   still support versions before that, but it's also super decrepit and
>   nobody runs it anyway. But wait -- the platform support says we only
>   care about 7.61.
> 
> - Shrug and grin. First patch in the series now bumps ./INSTALL to say
>   the minimum required curl is 7.59, and if anyone disagrees then it's
>   fair game to respond with. "fite me. The platform support says I don't
>   have to care, we are making this change whether you like it or not".

This is the approach we used to have, where we'd accept patches to support older systems if they weren't too invasive. It involved lots of heated discussions on the list that were unproductive and never came to a conclusion, and they'd repeat with some frequency. That's why we have the policy we have now: because it's clearer and more definitive and arguing extensively about what we were supporting was not in the interests of a healthy community for the project. It is also more honest in that we're clearly communicating to users whether they can expect things to work out of the box or whether they'll need to carry custom patches on their own.

Overall, people don't update the INSTALL documentation and it's routinely out of date. Should they? Yes, but practically they don't, and we don't test that, so we don't know if it's accurate.

> The important distinction here is that in this model, the install
> requirements aren't about what you want to spend time on supporting,
> they are about truthfully communicating what *works* in point of fact.

While this sounds nice in principle, it doesn't work in practice. We don't test things like MIPS or UltraSPARC hardware because we don't have CI systems that use that hardware and they're extremely slow in emulation, but we do want to support them if they're on an otherwise supported OS. Similarly, we probably do want to support NetBSD, but have no tests for it.

We also don't have situations where, in general, people are willing to compile their own set of software from scratch. For example, I'm not compiling an arbitrary libcurl version to test a problem on the list. With very few exceptions, the versions people use are tied to their distribution or vendor. If someone asks to support libcurl 7.19, we either have to custom compile that to test or try to run CentOS 6, which no longer runs in a Docker container on a modern kernel and has no security support, so practically the answer is no.

So we don't know for certain what does and does work, but we do know what we're willing to fix and support.

-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA