On Thu, Aug 10, 2017 at 07:09:02PM -0400, Jeff King wrote:
> The first is "should we eventually drop support for antiquated versions
> of dependencies?". And the argument in favor is the one I was making
> here: besides lowering maintenance cost, it is more honest to our users
> about what to expect[1].
As usual, I forgot all my footnotes.
[1] When I've talked about keeping expectations reasonable, I'm a lot
less interested in "oops, I built Git and this particular feature
didn't work". It's easy to write that off as "well, you have an old
version of curl, patches welcome". I'm much more concerned about
security issues. Curl is network-facing. Leaving aside security
vulnerabilities in curl itself (which hopefully distros with 10-year
support periods would fix), I wouldn't be surprised if there are
bad interactions possible due to our tangle of ifdefs.
One way to address that would be more careful auditing. But then
that goes back to the cost/benefit thing.
> One is to do it by date and what dependencies are in long-term OS
> releases, and then compare that to the benefit. Requiring curl 7.11.1
> still keeps us working back to rhel4, which was already end-of-lifed
> completely after a 12 year run. Bumping to 7.16.0 drops rhel4 and rhel5,
> the latter of which is in its final "barely supported" phase after 10
> years. But it gives us a bit more bang for our buck by making CURL_MULTI
> uconditional[2]. Requiring 7.19.4 actually doesn't drop any more rhel
> releases. So by that metric, we might as well go there.
[2] The line-count change from dropping CURL_MULTI isn't _too_ exciting.
But a lot of the tangled design of our http code revolves around
the abstractions we've introduced. I have a feeling that it will
enable further cleanups as we move forward (OTOH, a lot of the worst
parts of our design are because of _using_ curl_multi for dumb http,
which of course hardly anyone does these days. But I have a feeling
if I suggested removing that, people would really scream).
-Peff
