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@xxxxxxxxxxxxxxxxxxxxx/ > > > > 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.
