Re: [RFC] dropping support for ancient versions of curl

From: Stefan Beller <sbeller@google.com>
Date: Apr 4, 2017, 23:03 UTC
Message-ID: <CAGZ79kb5VeKCzzafw+nEcRda2apuit-K=qZxxZ3Li96MiMdOXA@mail.gmail.com>
In-Reply-To: <alpine.DEB.2.20.1704050043370.4268@virtualbox>

On Tue, Apr 4, 2017 at 3:46 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 20 quoted lines

> Hi Brandon,
>
> On Tue, 4 Apr 2017, Brandon Williams wrote:
>
>> I'm all for seeing a patch like this applied.  I agree that we can't
>> expect the world to be running the most up-to-date version of curl but
>> we should be able to select some "oldest" version we will support which
>> can be bumped up every couple of years.
>>
>> I mean, ensuring that you are running with an up-to-date version of curl
>> is really important when it comes to all of the security fixes that have
>> been made in each revision.
>
> I am not in the business of dictating to others what software they have to
> run. I am in the business of maintaining Git for Windows. And part of that
> job is to drag along code that is maybe not the most elegant, but works.
>
> The patch in question resolves such a wart. Sure, it would be a cleanup.
> Is it a huge maintenance burden to keep those few #ifdef's, though?
> Absolutely not.

Keeping them around is the easy part, the hard part is promising to users that the software you maintain is as good as your reputation, when e.g. we find out that certain #ifdefs don't even compile. (See Frank Gevaerts answer)

So from my point of view it ought to be easier to maintain software that is fully compiled and tested by a lot of people, and not have a long tail of niche features that are not well tested.

Initially I thought I had a similar stance as you ("A well written line of code is cheap") but I kept quiet, as I do not have a lot of experience with dealing "old" Software.

Maybe the git community would want to take a look at the kernel community (or other similar communities), how they solve the "long term stable" problem of computer science.

And there are different things to be considered: (1) the kernel community has "stable" maintainer(s) that are not the same as the maintainer of the bleeding edge branch. So I would expect that these maintainers have expertise in "dealing with old stuff, particular from $DATE_RANGE". (2) one of the kernels rules is "don't break user space". However sometimes they do remove code[1]. And then their policy seemed to be: Wait until someone shows up and we can revert the removal.

[1] http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html

So I would propose to take this patch, but be prepared to revert it in case some user yells.

Thanks, Stefan