From: "Torsten Bögershausen" <tboegi@web.de>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: "Alejandro R. Sedeño" <asedeno@mit.edu>,
"Taylor Blau" <me@ttaylorr.com>,
git@vger.kernel.org, sandals@crustytoothpaste.net,
asedeno@google.com
Subject: Re: [PATCH 0/2] Restore support for older libcurl and fix some typos
Date: Thu, 17 Oct 2024 08:59:37 +0200 [thread overview]
Message-ID: <20241017065936.GA16141@tb-raspi4> (raw)
In-Reply-To: <CAPig+cRENnd9cV5yFfVVwbuux84k10_vcht-TTtKGJmRNYEttA@mail.gmail.com>
On Tue, Oct 15, 2024 at 02:29:33AM -0400, Eric Sunshine wrote:
> On Mon, Oct 14, 2024 at 8:51 PM Alejandro R. Sedeño <asedeno@mit.edu> wrote:
> > On Mon, Oct 14, 2024 at 8:28 PM Taylor Blau <me@ttaylorr.com> wrote:
> > > On Mon, Oct 14, 2024 at 09:13:44AM -0400, Alejandro R. Sedeño wrote:
> > > > This is presented as an alternative to the patch series from
> > > > brian m. carlson that bumps the minimum version of libcurl
> > > > to 7.61.0 [3].
> > >
> > > This conflicts with brian's series as you mention, so I haven't picked
> > > this one up in 'seen' yet.
> > >
> > > Could you summarize why you think this series is a better approach than
> > > what brian has posted? On its own, I do not understand the motivation.
> >
> > It's a question of preserving compatibility vs ratcheting up minimum
> > requirements. Both have their merits. I sent in this patch set after
> > seeing some mild pushback to brian's series, just to present an
> > alternative. Maintaining compatibility with older versions can be a
> > burden to the project, though I think given this patch series, it's
> > not a very big one. Ratcheting up the minimum requirements can be a
> > burden to users stuck on (or choosing to try and support) older
> > platforms. At some point the burden on the project outweighs the
> > desire to support those older platforms. Where that tipping point is
> > is for the community to decide.
>
> For reference, I'm the one who pushed back on brian's series. The
> "push-back" subthread starts at [1].
>
> [1]: https://lore.kernel.org/git/20241014132856.3558224-1-asedeno@mit.edu/T/#mc1180f00cf52de4e9bae334c2cd5abd9a160dbbe
>
Being one of the people who has to work with older distributions,
I think that I would support the pushback.
There are many machines out there,
which are still running in production with old installations.
In my case it is a Centos 7 machine, coming with Git 1.8.3.1
Out of my head, git submodules didn't work (as good as today),
and even things like git -P didn't exist then.
I may be worth to mention that this machines are protected by double
or triple firewalls, routing tables, and whatever is needed to protect
them.
Maintaining production software and hardware, systems using specialized hardware
with Linux drivers dependend on the Linux kernel is daily work.
And here tools like Git are needed (and appreciated).
My view is that the new developments can focus on the "latest" distributions,
and if some comes along and has a patch that make Git
compile and work under an older system, and that patch does not break
newer systems, it would be a good thing to accept.
The seen branch from October 11 does not compile (any more) under Centos 7.
One problem is the curl stuff.
And then some warning, missing a prototype for lstat() in clar.c/fs_copy().
And warnings about missing braces around initializers, nothing
to worry about.
Lets try a summarize:
I can volunteer to compile Git from seen on this Centos box,
lets say once a week, and report breakages.
Other toughts ?
next prev parent reply other threads:[~2024-10-17 6:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-14 13:13 [PATCH 0/2] Restore support for older libcurl and fix some typos Alejandro R. Sedeño
2024-10-14 13:13 ` [PATCH 1/2] Conditional use of CURLOPT_PROXYHEADER based on libcurl version Alejandro R. Sedeño
2024-10-14 13:13 ` [PATCH 2/2] Fix inconsistencies in git-curl-compat.h Alejandro R. Sedeño
2024-10-15 0:28 ` [PATCH 0/2] Restore support for older libcurl and fix some typos Taylor Blau
2024-10-15 0:51 ` Alejandro R. Sedeño
2024-10-15 6:29 ` Eric Sunshine
2024-10-15 19:22 ` Taylor Blau
2024-10-17 6:59 ` Torsten Bögershausen [this message]
2024-10-17 9:15 ` Oswald Buddenhagen
2024-10-17 9:30 ` Torsten Bögershausen
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241017065936.GA16141@tb-raspi4 \
--to=tboegi@web.de \
--cc=asedeno@google.com \
--cc=asedeno@mit.edu \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=sandals@crustytoothpaste.net \
--cc=sunshine@sunshineco.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.
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 NNTP newsgroup(s).