RE: 7.62.0 brings lots of news, test it early!
> This is just a small request and reminder that if you can, we will appreciate > if you get and try out a recent daily snapshot of curl in your application or > environment as an extra precaution to verify that we haven't broken anything > significantly! Sorry for the stupid question, I don't have the cycles to watch the curl process as closely as I'd like. Does pulling from git and building from HEAD equate to the same thing or is there a tag (or a stream of tags) I'd be better to build from? Thanks /R --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Parallelizing tests
On Mon, Oct 01, 2018 at 11:58:25AM +0200, Daniel Gustafsson via curl-library wrote: > I was poking a little at parallelizing the test suite in order to try and > shave > some time off the total runtime. But before sinking time into that I wanted > to > ask if there are/have been any other attempts at this? Has anyone hacked on > this and if so, are there any learnings that can be shared? I have a local branch I started after the discussions during curl://up Nürnberg on the topic. I got 80% of the way to running tests on different protocols in parallel (I could do it but it required manually starting two test harnesses and selecting nonconflicting test ranges). Most of the changes involved making each test independent in its use of input and output files so there would be no conflicts at run-time. The test code has changed in the 1.5 years since, so it would be a bit of work to rebase it all to the current code. In retrospect, I probably should have checked in each part as it was complete, but since few of the changes on the way really helped improve curl without the entire thing being in place, I didn't. The other problem with the approach I was working on, namely, parallelizing by protocol but coordinating all the tests from a single test harness with a single set of test server (as it is mostly done today), is that the speedup would be limited. While it would be relatively straightforward to implement, you wouldn't see more than a 2× speedup since more than half the tests involve a single protocol, HTTP. A slightly different approach would involve starting N entire test harnesses in parallel, each responsible for its own suite of test servers running on its own range of test ports and running in its own tests/log/ directory. Since nothing would be shared between the test servers besides the input files, there would be no limit to the number of test harnesses (and therefore parallel tests) that could be run at once. If I were looking at the problem again, that's the approach I would take. It might even end up requiring fewer changes than the approach I was working on. To give a quick sketch, the test harness would open a pipe and fork() itself fairly soon after startup, putting the forked copies into slave mode and listening on the pipe for instructions. The master test harness would determine the tests to run as it does today, but rather than running them itself, it would send a message to one of the slaves that would actually run the test. The master would gather the result of each test run and display it to the user as it completes. The user wouldn't notice any difference except that the order of tests would no longer necessarily appear sequentially (a faster test result would be shown before a slower one that starts at the same time). Some of the infrastructure changes I made would be really useful in this approach as well, as I refactored the main test loop to make such a model easy to fit in. I can publish my branch somewhere if someone would find it useful, or even rebase the more generally-useful useful cleanups if you're not in a hurry. >>> Dan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Parallelizing tests
On Mon, 1 Oct 2018, Daniel Gustafsson via curl-library wrote: I was poking a little at parallelizing the test suite in order to try and shave some time off the total runtime. But before sinking time into that I wanted to ask if there are/have been any other attempts at this? Has anyone hacked on this and if so, are there any learnings that can be shared? Just some random thoughts of mine on the subject. We talked about it during curl up 2017 and I think Dan Fandrich did some attempts on it that never landed. The test suite fires up a set of independent test servers on different ports. Some of these servers are controlled by a file with fixed name ($LOGDIR/ftpserver.cmd) and they're sharing a lot of fixed output file names. If the parallelizing is to be done without containers, one approach would be to make sure that different protocol tests are run at the same time and that the servers don't share anything at all. It could then get further parallelized by runnning more servers on multiple ports so that HTTP for example, which I guess has the largest number of tests, could run N tests in parallel. If we instead go with an infrastructure that uses containers somehow, I suppose it will be simpler to parallelize protocols as each container could run its own test server and yet stick to the same port. -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
7.62.0 brings lots of news, test it early!
Hi! This is just a small request and reminder that if you can, we will appreciate if you get and try out a recent daily snapshot of curl in your application or environment as an extra precaution to verify that we haven't broken anything significantly! 7.62.0 has an unusual amount of new features crammed in. Because of this, I'd say there's a slightly higher risk than normal that we have let a mistake or two slip in. When we catch some of those mistakes *before* release, things are just so much better... During September 2018, we've added 11,276 lines of code and removed 5,555 lines. It is way more than usual and this much code churn in a single month has not happened in several years. And 7.62.0 is still almost a month away. The two primary reasons for the changed code lines are: DoH support and the new URL API. In particular the latter caused quite a few changes since our URL parsing was really spread out all over so unifying it to a single parser was... work. I'm not saying our testing is weak. On the contrary, I think our testing has never been stronger or more fierce than today. OSS-Fuzz still hammers on curl non-stop. Coverity reports zero defects. scan-build finds no flaws and all test cases run fine with and without valgrind run fine on 30+ builds for every commit. It's just that some things always remain untested in spite of all our efforts... -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Parallelizing tests
I was poking a little at parallelizing the test suite in order to try and shave some time off the total runtime. But before sinking time into that I wanted to ask if there are/have been any other attempts at this? Has anyone hacked on this and if so, are there any learnings that can be shared? cheers ./daniel --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
feature freeze time again
Hey friends, If you've been with us for a while, you know the drill. On this Wednesday, October 3rd, the feature window closes for this time. There will be no more changes/features merged for the 7.62.0 release after that day. If you have a new feature you'd like to get merged for this release, you better hurry up. While the feature window is closed, we will only merge bug-fixes into master. Features can still be posted as pull-requests, but they won't be merged into master before the window reopens. The feature window will remain closed until the pending release, planned to happen on October 31. -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
