git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Tom G. Christensen" <tgc@jupiterrise.com>,
	"Git Mailing List" <git@vger.kernel.org>,
	"Jonathan Nieder" <jrnieder@gmail.com>,
	"Todd Zullinger" <tmz@pobox.com>
Subject: Re: [RFC] dropping support for ancient versions of curl
Date: Fri, 7 Apr 2017 13:18:30 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1704071257560.4268@virtualbox> (raw)
In-Reply-To: <20170406092942.ow4mvce5miyzbgld@sigill.intra.peff.net>

Hi Peff,

On Thu, 6 Apr 2017, Jeff King wrote:

> And it's not like people on ancient mission-critical systems get cut
> off. They can still run the version of Git they were running when their
> OS went out of support.

You keep baiting me, so I'll bite, after resisting the urge for so long.

Let me share a little story of my own. So that this is not some academic,
theoretical wanking off, but something very tangible, very concrete, and
something very hard to handwave away.

As you know, in my previous job I was working as a scientist. Part of my
job was to support other scientists e.g. when they were using that really
big, really expensive, really advanced and super cool microscope. The
"really advanced" part only applied to the hardware, though, they were
running a super old CentOS, and everything was clamped down pretty good
(as many microscope vendors are wont to do), so there was no way to
upgrade the OS (I do not recall whether the drivers were only available
for this particular version of CentOS, but it would make sense, wouldn't
it, now, as microscope vendors are much more of experts in microscope
hardware than in anything vaguely related to software, even if they like
to pretend to be experts in both).

I did have access to gcc, though. And I did have to get Git working to be
able to install and develop additional software on that machine. It did
take me a while to get things to compile because of ancient libraries
being installed on that machine. Since only trusted people were allowed to
use that machine, security on that box was not really an issue. It did
make work for my colleagues substantially easier once I could develop on
that machine, using Git.

Just imagine how thankful I was that support for these old library
versions was almost working, still, and the one bigger problem I had was
easily solved by a patch that a quick web search found!

This. This is the impact of supporting older library versions, even if
they are long EOL.

Do not get me wrong: I am all for dropping support that is a huge
maintenance burden. You probably do not know the full back story, but let
me tell you what a relief it was to drop Windows XP support in Git for
Windows (and the Cygwin developers can sing several epic, Lord of the
Rings sized war songs about that, too).

At the same time, I want us to do better than all those maintainers out
there who drop backwards-compatibility just for the heck of it, not
because it would be a huge maintenance burden. "Everybody should upgrade,
anyway" is usually the naive excuse for not knowing why users are often
unable to upgrade.

Git is incredibly popular, and part of that is due to us being inclusive
and open and supporting a wide range of platforms. Yes, we can always do a
better job, that is true. We are also doing pretty well, though, and I
think that part of the reason is that we weigh carefully the maintenance
cost against the benefit of our users. Tiny "cleanup" patches that fail to
improve the maintenance burden substantially, and that also make users'
lives harder, are rightfully rejected. A little harder work from us
maintainers goes a long way to make a lot of users a lot happier.

My former self in my former life as a scientist is very thankful for the
consideration that goes into each and every "should we drop supporting
XYZ?" decision.

Very, very thankful.

Ciao,
Dscho

  reply	other threads:[~2017-04-07 11:19 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-04  2:54 [RFC] dropping support for ancient versions of curl Jeff King
2017-04-04  3:08 ` Jeff King
2017-04-04  5:44   ` Jessie Hernandez
2017-04-04  8:17 ` Ævar Arnfjörð Bjarmason
2017-04-04  8:33   ` Jeff King
2017-04-04 10:44     ` Ævar Arnfjörð Bjarmason
2017-04-04 11:54       ` Johannes Schindelin
2017-04-04 14:06         ` Ævar Arnfjörð Bjarmason
2017-04-04 16:53           ` Brandon Williams
2017-04-04 22:46             ` Johannes Schindelin
2017-04-04 23:03               ` Brandon Williams
2017-04-04 23:03               ` Stefan Beller
2017-04-05  8:49                 ` Johannes Schindelin
2017-04-05  9:29                   ` Jeff King
2017-04-04 20:16           ` Jeff King
2017-04-04 13:32 ` Frank Gevaerts
2017-04-05  9:33 ` Tom G. Christensen
2017-04-05 10:51   ` Ævar Arnfjörð Bjarmason
2017-04-05 13:04     ` [PATCH 0/7] Patches to support older RHEL releases Tom G. Christensen
2017-04-05 13:04       ` [PATCH 1/7] Make NO_PERL_MAKEMAKER behave more like ExtUtils::MakeMaker Tom G. Christensen
2017-04-05 13:04       ` [PATCH 2/7] Install man pages when NO_PERL_MAKEMAKER is used Tom G. Christensen
2017-04-05 13:04       ` [PATCH 3/7] Allow svnrdump_sim.py to be used with Python 2.2 Tom G. Christensen
2017-04-05 13:40         ` Ævar Arnfjörð Bjarmason
2017-04-05 14:36           ` Tom G. Christensen
2017-04-05 13:04       ` [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7 Tom G. Christensen
2017-04-05 13:50         ` Ævar Arnfjörð Bjarmason
2017-04-05 15:58           ` Franke, Knut
2017-04-05 13:04       ` [PATCH 5/7] Add support for gnupg < 1.4 Tom G. Christensen
2017-04-05 13:45         ` Ævar Arnfjörð Bjarmason
2017-04-13  6:31           ` Junio C Hamano
2017-04-13 15:17           ` Ævar Arnfjörð Bjarmason
2017-04-05 13:04       ` [PATCH 6/7] Handle missing CURLINFO_SSL_DATA_{IN,OUT} Tom G. Christensen
2017-04-05 13:52         ` Ævar Arnfjörð Bjarmason
2017-04-05 13:04       ` [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0 Tom G. Christensen
2017-04-05 13:53         ` Ævar Arnfjörð Bjarmason
2017-04-06  9:18         ` Jeff King
2017-04-13  6:28           ` Junio C Hamano
2017-04-13 10:52             ` Jacob Keller
2017-04-05 13:04     ` [RFC] dropping support for ancient versions of curl Tom G. Christensen
2017-04-06  0:53     ` brian m. carlson
2017-04-06  1:16       ` Todd Zullinger
2017-04-06  9:29       ` Jeff King
2017-04-07 11:18         ` Johannes Schindelin [this message]
2017-04-10 18:22           ` Jeff King
2017-04-06  9:21   ` Jeff King
2017-04-06 16:43     ` Tom G. Christensen
2017-04-07  4:54       ` Jeff King
2017-04-14 11:12         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1704071257560.4268@virtualbox \
    --to=johannes.schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.net \
    --cc=tgc@jupiterrise.com \
    --cc=tmz@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).