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: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 22 Mar 2023 08:45:27 +0100 (CET)
On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
> On a related note, what's the current code coverage? I haven't tried myself
> in a looong time, and there hasn't been a Coveralls build in 5 years. That
> would be a great graph to see on https://curl.se/dashboard.html But with all
> the different build configurations it would be hard to get a single
> meaningful number out of it; maybe that's why it hasn't happened since then.
Yes. It is practically impossible for us to get a fair or even just almost
correct coverage number due to the many build combinations and the way we run
different tests in different jobs etc.
And apart from not getting the plain number, using the coverage data to detect
untested code paths is then also similarly complicated.
If that was not enough, the coveralls service itself was flaky and often
triggered false positives when the coverage suddenly "dropped to 0%" etc.
Also, frankly, even when we *know* what parts that aren't tested very well
that does not make the masses come running to help us write new or expand old
tests to increase coverage. I am pretty sure that we can dig up code areas
that currently are not tested well without any particular tools. Right now.
Date: Wed, 22 Mar 2023 08:45:27 +0100 (CET)
On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
> On a related note, what's the current code coverage? I haven't tried myself
> in a looong time, and there hasn't been a Coveralls build in 5 years. That
> would be a great graph to see on https://curl.se/dashboard.html But with all
> the different build configurations it would be hard to get a single
> meaningful number out of it; maybe that's why it hasn't happened since then.
Yes. It is practically impossible for us to get a fair or even just almost
correct coverage number due to the many build combinations and the way we run
different tests in different jobs etc.
And apart from not getting the plain number, using the coverage data to detect
untested code paths is then also similarly complicated.
If that was not enough, the coveralls service itself was flaky and often
triggered false positives when the coverage suddenly "dropped to 0%" etc.
Also, frankly, even when we *know* what parts that aren't tested very well
that does not make the masses come running to help us write new or expand old
tests to increase coverage. I am pretty sure that we can dig up code areas
that currently are not tested well without any particular tools. Right now.
-- / 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-03-22