| Message ID | 20241014131346.3556163-1-asedeno@mit.edu (mailing list archive) |
|---|---|
| Headers | show |
| Series | Restore support for older libcurl and fix some typos | expand |
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. Thanks, Taylor
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 my own personal purposes, I've worked around the issue by building a newer libcurl to link git against, though brian's updates to the perl minimum requirements will pose a more substantial problem for me in the future. -Alejandro
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
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 OK. Junio had brian's series in 'seen' when I picked up the integration branches on Friday evening. Let's keep it that way for now while we wait to see what approach between the two is preferred. Thanks, Taylor
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 ?
On Thu, Oct 17, 2024 at 08:59:37AM +0200, Torsten Bögershausen wrote: >Maintaining production software and hardware, systems using specialized >hardware with Linux drivers dependend on the Linux kernel is daily >work. > yes. >And here tools like Git are needed (and appreciated). > but why? why do you need bleeding edge git on these special-purpose systems from the stone age? wouldn't any sane developer (cross-)build on a modern system (which usually has about an order of magnitude more computing power, aside from the newer tools) and then deploy and extract only what's needed via some mostly automated process? it would only matter if git was part of the production software (what for?), but then we're back to square one.
Just a short update: This make git compile (again) on the mentioned centos system.