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

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

Hi Stefan,

On Tue, 4 Apr 2017, Stefan Beller wrote:

> On Tue, Apr 4, 2017 at 3:46 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > 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)

From that point of view, we should drop support for platforms as soon as
we have a bug in our code that lets the build fail: there is little
difference between the #ifdef's that let Git build with older dependencies
and #ifdef's that let Git build on platforms other than Linux.

By that reasoning, we would have dropped FreeBSD support a gazillion
times. Or for that matter, Windows support.

I obviously disagree with this stance.

> 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.

I am speaking from my point of view, of course, maintaining Git for
Windows. Of course I would love to drop support for old MSys. But that's
not going to happen because at least one active contributor has a vested
interest in keeping it going.

But even then, it sometimes takes a while until any breakages get fixed.
Prematurely removing a build option "because it has been broken for a
couple of major versions" would make it infinitely harder for (often
overworked) contributors to fix the breakage.

Anyway, this whole discussion took way more effort from my side than to
maintain a couple of slightly stale #ifdef's. From
https://xkcd.com/1205/'s point of view, I should have ignored the
"let's rip out stuff just because we can" patch.

I just thought that we care a bit more about contributors' experience.

> 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.

If we want to follow the example of a inclusive community that values
contributors' time and effort, maybe we should look elsewhere?

I vividly remember hearing Greg KH's statement at Git Merge 2016 "we
deliberately waste contributors' time". Very vividly. Very, very vividly.

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

It would be much nicer to contributors (who are likely not subscribed to
the Git mailing list, or at least do not read all the mails coming in on
that channel) if they could simply imitate the surrounding #ifdef's and
make that tiny patch that adds a guard around an unused static function.

If you require them to revert a patch first that reinstates an almost
working state with an old dependency, you expect them to know that there
was such a patch in the first place, and to dig it up.

Let's reiterate that we are talking about some #ifdef's here that are a
tiny maintenance burden. That may have a bug here and there, easily fixed.

Again, I am sure that we can provide a much better contributors'
experience.

Also, maybe, just maybe, there are more pressing issues than removing a
couple lines here and there? This discussion vaguely reminds me of the
opening statement of https://en.wikipedia.org/wiki/Law_of_triviality...
Just saying'...

Ciao,
Dscho