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: On more stable curl releases
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Kamil Dudka via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 22 Mar 2023 09:24:24 +0100
On Wednesday, March 22, 2023 8:34:30 AM CET Daniel Stenberg via curl-library wrote:
> On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
>
> > It would be great if we can find more people to test pre-release curl
> > versions
>
> I believe that is the holy grail we can only dream of. People are simply
> hesitant to try pre-releases. Granted, we haven't tried this for a long time
> but we also know that barely anyone tries and finds issues in the nightly
> builds we provide every day.
Speaking of Fedora/CentOS, we could enable Packit in the upstream CI:
https://packit.dev/
It automatically builds RPM packages for a matrix of supported Fedora/CentOS
releases and the supported architectures, upon each pull request or update in
the master branch.
A successful build of RPMs implies that the upstream test-suite succeeded and
the tests runs through valgrind on x86_64. The service also automatically
creates package repositories (one for master branch and one for each pull
request), which volunteers may consume to continuously test (lib)curl on their
systems.
Is this something that curl upstream would be interested in?
The key problem I see with this approach is that Fedora developers do not have
enough time to monitor and debug the (mostly random) failures of the upstream
tests. And I think this is the main problem with the upstream CI already. If
you look at the recent pull requests, you could hardly find one with green CI.
Kamil
> > Maybe we should label the daily snapshot one week before a scheduled release
> > as "rc1" and promote it that way and see what happens?
>
> That is a very cheap test we can certainly do. I'm pretty sure what the
> outcome will be though...
Date: Wed, 22 Mar 2023 09:24:24 +0100
On Wednesday, March 22, 2023 8:34:30 AM CET Daniel Stenberg via curl-library wrote:
> On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
>
> > It would be great if we can find more people to test pre-release curl
> > versions
>
> I believe that is the holy grail we can only dream of. People are simply
> hesitant to try pre-releases. Granted, we haven't tried this for a long time
> but we also know that barely anyone tries and finds issues in the nightly
> builds we provide every day.
Speaking of Fedora/CentOS, we could enable Packit in the upstream CI:
https://packit.dev/
It automatically builds RPM packages for a matrix of supported Fedora/CentOS
releases and the supported architectures, upon each pull request or update in
the master branch.
A successful build of RPMs implies that the upstream test-suite succeeded and
the tests runs through valgrind on x86_64. The service also automatically
creates package repositories (one for master branch and one for each pull
request), which volunteers may consume to continuously test (lib)curl on their
systems.
Is this something that curl upstream would be interested in?
The key problem I see with this approach is that Fedora developers do not have
enough time to monitor and debug the (mostly random) failures of the upstream
tests. And I think this is the main problem with the upstream CI already. If
you look at the recent pull requests, you could hardly find one with green CI.
Kamil
> > Maybe we should label the daily snapshot one week before a scheduled release
> > as "rc1" and promote it that way and see what happens?
>
> That is a very cheap test we can certainly do. I'm pretty sure what the
> outcome will be though...
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-03-22