On 04/04, Ævar Arnfjörð Bjarmason wrote: > On Tue, Apr 4, 2017 at 1:54 PM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > Hi, > > > > On Tue, 4 Apr 2017, Ævar Arnfjörð Bjarmason wrote: > > > >> I think it's completely fine to include your patch as-is. At some > >> point we need to pass the burden of dealing with these old software > >> versions, saying that you should use a <10 year old library isn't > >> unreasonable. Anyone packaging new git on RHEL5 or derivatives can > >> just package a newer libcurl as well. > > > > But how much maintenance burden is it, really? Is the continued use of > > those #ifdef's really worth this much discussion, let alone applying a > > patch that may break users who have so far been happy? > > > > It would be a different thing if we had to have hacks to support old cURL > > versions, where we need to ship entire >10kB source files that tap into > > internal data structures that may, or may not have changed. Such a hack, I > > would be happy to discuss when we could possibly remove it. > > > > But a couple of #ifdef's? C'mon, man, we can carry this *without sweat* > > indefinitely ;-) > > I don't really care about applying this patch, but I wouldn't mind > seeing it applied. > > I just wanted to clarify the counteractive point that it's not unusual > for some (particularly corporate) environments to be compiling fresh > upstream releases of some software against really ancient versions of > other upstream libraries. > > But as Frank Gevaerts's reply (thanks!) which came after your reply > points out, this code has already been broken since v2.12.0, so it's > rarely used enough that nobody's reported being unable to compile git > 2.12.0 on e.g. CentOS 5 >2 months since release. > > I think this is a stronger argument for removing stuff like this. At > some point we're shipping code nobody's tested in combination with the > rest of our code. This can easily becomes a source of bugs as someone > e.g. compiling a new git on co5 becomes literally the first person to > ever test some new combination of codepaths we've added around mostly > unused ifdefs. 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. -- Brandon Williams