On 7/18/23 23:03, Daniel Stenberg wrote:
On Tue, 18 Jul 2023, Patrick Monnerat via curl-library wrote:
I have made some local changes to gskit, in hope to save it form
deprecation (modernize, TLS 1.3, ALPN).
It compiles fine, but unfortunately I can't test it as the
certificate store access is denied on pub400. This is why I did not
submit a PR for it yet.
I'm a little tired of the fragile gskit situation. I'm willing to
re-evaluate once we see a CI job that builds and tests curl with
gskit. I want to (continuned to) raise the bar for what is an
acceptable level for supported TLS libraries in curl.
Because if nobody can make CI builds for gskit, then I don't think it
is that important either.
Yes, it is important because there are no alternative under OS400.
This is not a gskit problem, rather an OS400 one.
There's no CI for OS400 because 1) tests do no run on this platform; 2)
is there an OS400 CI environment available ?
No tests on OS400: would need perl among other features. These are
available under PASE which is an AIX emulation, but certainly not native
OS400.
For 16 years, the OS400 port has been tested manually to all users'
satisfaction.
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". You did not mention a CI. IMO, I now have
done enough developments that are not accepted, or even ignored.
Patrick
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
