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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024-10-22 at 03:34:25, Eli Schwartz wrote:
> 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.

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

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux