On 7/19/23 01:11, Daniel Stenberg wrote:
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?
From replies from others (many thanks to them!), it seems it is
feasible but is completely out of my skills, I'm afraid.
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.
This has occurred for 7 years only. And these are primarily compilation
problems, not related to gskit.
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.
Well, the definition of "in shape" is missing! My feelings back to
January was mainly TLS 1.3 and its crypto algorithms. I do have now such
a version that compiles, but still untested regarding its functionalities.
You did not mention a CI.
I do now. In 2023, not testing code regularly in CI is just lame.
This is probably true nowadays in our open-source word. I've never seen
such a practice or a standardized way of doing it on the OS400 world. I
have to admit that for 7 years, I'm not as involved in it as I was before!
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.
Yes, as already mentioned in the January thread, the OS400 world is
another planet where there are only users :-(
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.
Sure, providing we can reasonably use an infrastructure that allows it.
In the OS400 context, the infrastructure is not reasonable for what we
need and making it up by ourselves (whoever it is) is a project by itself.
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.
But users do. And I know some other commercial company we do care about,
that very frequently makes mistakes around our project and the
communication around it! That's even worse :-(
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.
As said before, TLS 1.3 is ready. And again, before a CI we must have
the test environment. But before August, this is just
https://www.youtube.com/watch?v=nsOnWtCxLKI !
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html