Re: [PATCH 0/4] dropping support for older curl

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Peff,

On Wed, 9 Aug 2017, Jeff King wrote:

> On Wed, Aug 09, 2017 at 11:42:12PM +0200, Johannes Schindelin wrote:
> 
> > > This is a resurrection of the thread from April:
> > > 
> > >   https://public-inbox.org/git/20170404025438.bgxz5sfmrawqswcj@sigill.intra.peff.net/
> > 
> > As before, I would like to point out that people running with older cURL
> > are most likely not at liberty to change the system libraries.
> > 
> > I know that I didn't when I was working on a very expensive microscope
> > whose only certified control computer ran a very old version of CentOS,
> > and I really needed to install Git on it.
> > 
> > In such a case, it is often preferable to be able to build against an old
> > cURL -- even if some of the fancier features might be broken, and even if
> > some minor compile errors need to be fixed.
> > 
> > I know I was happy to compile Git against an ancient cURL back then.
> > 
> > Just so you understand where I come from when I would like to caution
> > against dropping support for older cURL unless it *really* adds an
> > *enormous* amount of maintenance burden.
> > 
> > I mean, if we even go out of our way to support the completely outdated
> > and obsolete .git/branches/ for what is likely a single user, it may not
> > be the worst to keep those couple of #ifdef guards to keep at least
> > nominal support for older cURLs?
> 
> You've totally ignored the argument I made back then[1], and which I
> reiterated in this thread. So I'll say it one more time: the more
> compelling reason is not the #ifdefs, but the fact that the older
> versions are totally untested.  In fact, they do not even compile, and
> yet I have not seen any patches to fix that.

Let me re-quote from above:

> > In such a case, it is often preferable to be able to build against an
> > old cURL -- even if some of the fancier features might be broken, and
> > even if some minor compile errors need to be fixed.

As far as I remember, I *did* have to fix a minor compile error.  Took
something like 15 minutes from first compile error to fully running test
suite.

Compare that effort to the effort of compiling a current cURL, possibly
having to compile newer c-ares, spdylay, jansson, nghttp2, openssl,
nettle, libunistring, libtasn1, libidn, libmetalink, rtmpdump and whatever
else.

> So IMHO this is about being honest with users about which versions we
> _actually_ support.

We will most likely never, ever have a fully 100% bug free system. That
does not mean that we should rip out everything that is not totally,
completely working.

Instead, we try [*1*] to welcome patches.

I can buy some argument like: this support is so invasive, so brittle, and
nobody takes care of it, and if it breaks, it is hard to fix, and those
who could, won't, so let's remove it.

That argument is why Git for Windows dropped XP support.

I cannot buy the argument: there are a dozen #ifdefs and I don't know
whether they still work. I don't know whether anybody (who most likely has
better things to do than read the Git mailing list) is still using those.
So let's just remove them.

That argument was what let us go overboard, and actually go too far by
removing the fallback when REG_STARTEND is missing, even while fixing a
very real bug. And that overzealous action hurt users. It also cost *us*
time, having to deal with the ensuing conversation, but we deserved to be
paying for this, the users didn't.

I did not have time to look closely over your patches to remove cURL
support for older versions. From a cursory look, I did not get the
impression that there is a lot of maintenance burden there, though.
Therefore, I currently believe that the downsides of removing the support
outweigh the benefits.

Mind, I agree that cURL should be upgrade to version 7.55.0 wherever
possible. But it is a huge mistake to assume that everybody who wants to
build, or just use, Git is at liberty to perform that upgrade in their
setup. To make that assumption is really harmful to users who are stuck in
a bad place out of no fault of their own. It is also not very nice.

Hopefully I had better luck expressing my concerns this time?

Ciao,
Dscho

Footnote *1*: It is no secret that I find our patch submission less than
inviting. Granted, *I* use it. *I* did not have problems entering the
mailing list. But then, my mails were not swallowed silently, because my
mail program does not send HTML by default. And prepared by the German
school system (I learned the term "sugar coating" only when exposed to
some US culture), I had little emotional problems with being criticized
and not thanked for my contribution, I persisted nevertheless. The opinion
that the Git contribution process is a lot less inviting than it could be
is not only my view, by the way. I hear this a lot. I give you that we are
not quite as textbook "keep out from here unless you look like us, smell
like us, talk like us, have the same genital setup like us" as the Linux
kernel mailing list, but we are in a different universe compared to, say,
the Drupal community. And their universe is a lot nicer to live in.