Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: NSS and gskit are getting the axe
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 19 Jul 2023 01:11:07 +0200 (CEST)
On Wed, 19 Jul 2023, Patrick Monnerat wrote:
> There's no CI for OS400 because 1) tests do no run on this platform; 2) is
> there an OS400 CI environment available ?
I don't know. I don't see why there couldn't be?
> For 16 years, the OS400 port has been tested manually to all users'
> satisfaction.
I don't think that is true. Just about every release is shipped with broken
os400/gskit builds because nobody tests curl+gskit in CI and not from git
either. The fact we've had a bad situation for 16 years is not a very good
motivation to keep it. Back when we added gskit support we didn't test a
single TLS backend in CI builds. Now we test all TLS backends except gskit. We
would not dream of accepting a new TLS backend without it.
> If you have decided gskit cannot be saved from deprecation, please write it
> explicitly and avoid letting some "hope" on it: from your Jan 2 mail
> https://curl.se/mail/lib-2023-01/0003.html "If we get the gskit support in
> shape in time before August 2023, I think that is a working argument to
> *not* deprecate it then".
I don't see it "in shape" now. I have repeatedly said since, many times, that
gskit is up for deletion and yet not a single soul has spoken up about it. I
don't sense a strong desire to keep it around.
> You did not mention a CI.
I do now. In 2023, not testing code regularly in CI is just lame.
> IMO, I now have done enough developments that are not accepted, or even
> ignored.
You have done a lot, more than anyone I know, for OS400 and gskit in curl.
This is not a dis against you or any other individual. It just happens that
this area is *clearly* not valued very much by the community that uses it so
it has always remained in this weird half-assed state. Struggling.
I think we as a community has a responsibility to gradually enhance and
improve curl and over time trim it and cut out code and parts of the project
that can't keep up with this.
I think it can be saved. I just don't think the OS400 peeps are up for it. I
see no evidence of such attempts - other than from you Patrick. I value your
efforts, but I think it is rather lame that you as an individual should save
the port for a commercial operating system that virtually not a single private
person uses and everyone pays a lot of money for, but the companies themselves
don't care for curl on their platform.
In my mind, what would save gskit in curl would the very least be someone
setting up a CI for curl + gskit. Then refresh the code and support modern
things like TLS 1.3.
Date: Wed, 19 Jul 2023 01:11:07 +0200 (CEST)
On Wed, 19 Jul 2023, Patrick Monnerat wrote:
> There's no CI for OS400 because 1) tests do no run on this platform; 2) is
> there an OS400 CI environment available ?
I don't know. I don't see why there couldn't be?
> For 16 years, the OS400 port has been tested manually to all users'
> satisfaction.
I don't think that is true. Just about every release is shipped with broken
os400/gskit builds because nobody tests curl+gskit in CI and not from git
either. The fact we've had a bad situation for 16 years is not a very good
motivation to keep it. Back when we added gskit support we didn't test a
single TLS backend in CI builds. Now we test all TLS backends except gskit. We
would not dream of accepting a new TLS backend without it.
> If you have decided gskit cannot be saved from deprecation, please write it
> explicitly and avoid letting some "hope" on it: from your Jan 2 mail
> https://curl.se/mail/lib-2023-01/0003.html "If we get the gskit support in
> shape in time before August 2023, I think that is a working argument to
> *not* deprecate it then".
I don't see it "in shape" now. I have repeatedly said since, many times, that
gskit is up for deletion and yet not a single soul has spoken up about it. I
don't sense a strong desire to keep it around.
> You did not mention a CI.
I do now. In 2023, not testing code regularly in CI is just lame.
> IMO, I now have done enough developments that are not accepted, or even
> ignored.
You have done a lot, more than anyone I know, for OS400 and gskit in curl.
This is not a dis against you or any other individual. It just happens that
this area is *clearly* not valued very much by the community that uses it so
it has always remained in this weird half-assed state. Struggling.
I think we as a community has a responsibility to gradually enhance and
improve curl and over time trim it and cut out code and parts of the project
that can't keep up with this.
I think it can be saved. I just don't think the OS400 peeps are up for it. I
see no evidence of such attempts - other than from you Patrick. I value your
efforts, but I think it is rather lame that you as an individual should save
the port for a commercial operating system that virtually not a single private
person uses and everyone pays a lot of money for, but the companies themselves
don't care for curl on their platform.
In my mind, what would save gskit in curl would the very least be someone
setting up a CI for curl + gskit. Then refresh the code and support modern
things like TLS 1.3.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-07-19