Hi All, Not really active here any more. Thanks for picking up where we left years ago. Really happy to see that you all move to get things forward again.
+1 on what Branko mentioned here... Please be very careful with global state, being used. The rest is nicely per context. -------------- One thing I still have on my mind but not written down.... and mostly out of context here: What is not properly documented is that on Windows when you use Serf built as DLL the comparison of the functions in one of the Serf macros is not guaranteed to work... And in practice it doesn't work there, so the old vs new bucket type detection breaks. I think currently all Windows users work around this by using the build static. For the future I think we should get that address via a helper function to make sure we can do the ==comparison safely. For 1.3 ignoring those code paths is mostly safe, but for 1.5+ it should be made safe or the limitations documented ---- Thanks all, Bert On Sun, Jan 18, 2026 at 9:54 AM Branko Čibej <[email protected]> wrote: > On 11. 12. 25 19:59, Daniel Sahlberg wrote: > > Hi, > > > > Prompted by Evgeny's suggestion to move forward with releasing Subversion > > 1.15.0[1], I'd like to suggest getting a new minor release of Serf out of > > the door as well - preferrably first! > > > > There are a few features in Subversion that depend on recent development > in > > Serf (for example the error reporting) and it would be nice to have it > > released together. > > > > Brane has made a summary in Jira, see SERF-208[2], open points copied > below: > > * Generalized error callbacks, discussed in [3]. From what I can see we > > have an error callback mechanism that works for SSL errors. There is also > > code in Subversion to support this. We need to decide if [a] We are happy > > with the current situation, or [b] Can someone step up to improve it. > > Personally, I'm leaning towards [a]. > > * Issue SERF-195, which is a substantial rewrite of the request queues. > The > > code is in a separate branch SERF-195. The code looks good to me but I > > haven't analyzed in detail. It should be possible to merge to trunk. > > * Issue SERF-209, concerning intermitent test suite failures under > MacOS. I > > would suggest to leave this aside for later. > > > > Can we get these decided/merged and roll a release? I think it would be > > good to do this in trunk before branching. > > > > Kind regards, > > Daniel > > > > > > > > > > [1]https://lists.apache.org/thread/x0s1c8jolql5hdkq40jm3jfnpm6wjp9s > > [2]https://issues.apache.org/jira/browse/SERF-208 > > [3]https://lists.apache.org/thread/7khn697o2srmg8wvqy4t3xyxq4cr8v8v > > Everything mentioned in SERF-208 is now resolved. In addition to that: > > * I went through all the test failures with LibreSSL. They were all > just differences in the way errors are reported from the library, so > I adjusted the expected test output. > * I finally found the reason why some OCSP SSL tests failed on Fedora > and derivatives; the test code was creating a SHA-1 signature on > OCSP responses, but the OpenSSL shipped with Fedora forbids the use > of SHA-1 in this context. I fixed this by using SHA-256 in the test > code. > > > With the above two changes, I built and successfully tested trunk on: > ARM64 Windows; aarch64 Linux (Debian 12 and Fedora 43); aarch64 > (Free|Open|Net)BSD; and emulated x86-64 Haiku, just for the thrill of it. > > I think we're ready to release, pending API review. > > -- Brane >
