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? 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). ☐ 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. ☐ Review new and changed APIs for design and style (e.g. Doxygen mark-up, undocumented parameters, deprecation, public/private status, etc.). Comment: ... todo ... ☐ Run compatibility tests against the incumbent minor release. Comment: N/A? Cheers, Daniel
