On 4. 1. 26 17:40, Daniel Sahlberg wrote:
Den sön 4 jan. 2026 kl 10:07 skrev Branko Čibej<[email protected]>:
On 4. 1. 26 09:18, Daniel Sahlberg wrote:
In the interest of readability, I'm replying to an old e-mail here to
summarise the discussion else-thread.
Den tors 11 dec. 2025 kl 20:43 skrev Branko Čibej<[email protected]>:
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].
I'm not happy with the current custom callback just for SSL errors. I'd
be -0.9 to release it as a public API. I sort of dropped the ball .
Work is ongoing, with some committed to the repository and some still in
progress (including the earlier mail from Brane with a patch).
It seems we should be able to get this done not too far into the future.
* 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.
The patch works, in the sense that it causes no regressions, but I
haven't been able to reproduce the reported issue. It's also makes the
code slightly more readable, but I couldn't find the mentioned race
condition during review, it looks like just a refactoring of the
original code.
I think we need another pair of eyes to do a careful review of the
branch changes.
I have removed SERF-195 from the checklist as per consensus else-thread.
* Issue SERF-209, concerning intermitent test suite failures under
MacOS. I
would suggest to leave this aside for later.
Yes, it's not critical. Might be something in the test code itself,
i.e., not related to serf proper.
Can we get these decided/merged and roll a release? I think it would be
good to do this in trunk before branching.
FWIW: I've just rebuilt TortoiseSVN based on Serf trunk and the 1.15.x
branch of Subversion (with SVN__SERF_EXPERIMENTAL and
SVN__SERF_TEST_HTTP2
to let Subversion use some new Serf features. Build went fine and some
initial tests (checkout, commit) also worked as expected. I'll use this
on
my work laptop for a few days to test out
Cheers,
Daniel
We should also replace all the "@since New in 1.4" with 1.5, to avoid
confusion?
-- Brane
Yes, that is probably a good idea. Do you mind if I do it?
Sure. It's SERF-210 now.
I'm planning to update Graham's Subversion patch, utilising the error
callbacks, to the new callback structure to see how it would work out in
practice. That should go on another mailing list though.
If that works out, then I think we should get going with a release.
Borrowing the checklist Evgeny posted on Subversion 1.15:
🗹 Review the Roadmap. Should any of the outstanding items be addressed
before branching?
Comment: Discussed, in SERF-208 and in the mailing list. In short, two
issues were deferred to trunk/1.6 and all other closed except the error
callbacks.
☐ Review the incumbent stable branch's STATUS file for outstanding -0 and
-1 votes. Was code that is going to be included in the new branch objected
to?
Comment: N/A for Serf? We should probably still have such discussion after
reviewing the new APIs (below).
The "current stable branch" in our case is 1.3.x. Doesn't seem to be
anything there. Re LibreSSL, I've tested Serf builds on OpenBSD with
LibreSSL. Some SSL tests of course fail because of different error
reporting. We have special-caseing there for different OpenSSL versions,
we could add similar for LibreSSL – not too onerous since it advertises
as OpenSSL 2.x.
On that note, Fedora/Centos/RHEL have patched OpenSSL 3.x that has
stricter constraints, causing some of our SSL tests fail, too.
We don't really have to delay 1.5 for this as long as we review the
failures and decide they're cosmetic only. Those kinds of fixes can be
backported later.
I can take a look at the state of that again. I should be able to build
with LibreSSL on my mac, too.
☐ Do any tree-wide, mechanical changes.
Comment: I have not reviewed if there are any such changes for Serf, but I
assume there are at least some version #defines after branching.
SERF_MAJOR/MINOR_VERSION in serf.h and the @since 1.4 bits.
Copyright years in the file headers and the web site (which is still
2023; I didn't change that just because of the logo/font update).
☐ Review new and changed APIs for design and style (e.g. Doxygen mark-up,
undocumented parameters, deprecation, public/private status, etc.).
Comment: ... todo ...
Yes, our Doxygen markup isn't the best. As long as we have it for new
functions that appeared between 1.3 and trunk, I think we can live with
that.
☐ Run compatibility tests against the incumbent minor release.
Comment: N/A?
That would be something along the lines of running the 1.3 branch tests
with a 1.5 libserf, as far as it's feasible. Internal-test should be
skipped, but the rest should work.
Hm, that's a pain because the tests link with the static lib, oh well,
I'll give it a go.
Also running the Subversion test suite against a https:// mod-dav-svn
with trunk serf, with or without SVN__SERF_EXPERIMENTAL.
-- Brane
