Den ons 2 juli 2025 kl 18:17 skrev Ivan Zhakov <i...@apache.org>: > On Fri, 27 Jun 2025 at 11:43, Daniel Sahlberg <daniel.l.sahlb...@gmail.com> > wrote: > >> Hi, >> >> I'm very happy to see the rekindled interest in Serf development and the >> recent work by Brane on the user-defined-authn branch and by Graham on the >> OpenSSL "certificate by URI" PR. I'm planning on reviewing those things >> during the weekend. When these are merged (and it doesn't only depend on >> me, it is of course a team effort reviewing and merging!) we should start >> thinking about a new release. >> >> I don't think it makes sense to backport to 1.3 - they would add new APIs >> that require a version bump. >> >> The existing 1.4.x branch was created in 2018 and received a few backports >> the same year but it lacks significant work from trunk, for example >> Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10. >> >> I'm proposing to drop the current 1.4.x branch and create a new one based >> on trunk. Alternative option to drop 1.4.x completely and instead name the >> new release 1.5. >> >> As far as I understand trunk contains a bunch of HTTP 2-work, but >> according >> to Brane earlier on dev@ some is hidden behind #ifdefs that will only >> expose it if released as Serf 2. Would it make sense to get this released >> as well? In that case, should we instead aim for Serf 2.0? Alternative >> option to remove the #ifdefs and declare it stable in Serf 1. > > > I'd like to share an alternative perspective (my two cents) on this topic. > In short, I believe there are strong, practical reasons to merge Serf > directly into Subversion: > > 1. Based on publicly available information, Subversion is the only actual > user of Serf. > > I checked major Linux distributions (Ubuntu, Debian, CentOS, OpenSUSE) and > Subversion is consistently the only dependency listed for libserf: > - Ubuntu: > https://ubuntu.pkgs.org/25.04/ubuntu-universe-amd64/libserf-1-1_1.3.10-3ubuntu1_amd64.deb.html > - Debian: > https://debian.pkgs.org/12/debian-main-amd64/libserf-1-1_1.3.9-11_amd64.deb.html > - CentOS: > https://centos.pkgs.org/10-stream/centos-appstream-x86_64/libserf-1.3.10-7.el10.x86_64.rpm.html > - OpenSUSE: > https://opensuse.pkgs.org/15.6/opensuse-oss/libserf-1-1-1.3.9-150600.16.2.x86_64.rpm.html > bilities. > > This demonstrates a deep interdependency between the two projects. > > 5. Almost all Serf committers are also Subversion committers. > > This means that the actual development community is shared, rather > than diverse. > > 6. Merging Serf into Subversion would eliminate the need to reinvent > various patterns in Serf, such as svn_error_t. > This could allow reusing existing common primitives within Subversion. > > 2. Some popular package managers like Homebrew don't even offer libserf as > a separate package, also indicating its lack of independent adoption. > > 3. While I appreciate Serf's internal design and implementation, I think > there are no compelling reasons to choose it for a new project over > alternatives like libcurl. > > For example, libcurl offers comprehensive support for: > - Authentication types (SSPI, CRAM, SASL, OAuth2, Kerberos, etc.) > - TLS implementations (OpenSSL, Schannel, BearSSL, GnuTLS, Mbed TLS, > Rustls, wolfSSL) > - Modern protocols (HTTP/2, HTTP/3) > > Serf's primary advantage, which I believe is in how it handles > asynchronous multiplexing, doesn't appear to be a widely demanded feature > for most users. > > 4. Subversion is already developing new features that rely on unreleased > Serf APIs and capa > > With these points in mind, merging Serf into Subversion could be a logical > step. It would simplify new feature development, allowing more focus on > features and less on API and build dependencies. >
Thanks Ivan for a well formulated e-mail on this topic. I think it is a question that makes a lot of sense to think about. I believe it would make sense for Subversion to absorb Serf IF one of these two conditions are true: * We have trouble releasing Serf (no problem during the release of 1.3.10). * If Subversion believe it could simplify the code and/or implement new features much easier. The first point is mainly a problem for the Serf community. The second point might make sense for Subversion with regard to the recent discussion about error reporting - Subversion could simply kill the Serf-APIs that doesn't make sense for Subversion. This discussion probably belong in dev@subversion. Realistically it would probably kill Serf. I have made the same observation as Ivan regarding open source users of Serf. Apache OpenOffice used to bundle Serf but switched to Curl about two years ago. (Last time it was discussed, Greg pulled out some download statistics[1] (500 downloads per day for the last two months), arguing that Serf is highly used. However looking at OS (87% on macOS) and Browser (87% by curl) lead me to believe most if from MacPorts (as a build dep for Subversion) - for sure we have approx 65 daily downloads that isn't MacPorts but that is far from widely used). It would really help if the closed source users could chime in and potentially help making sure Serf stays healthy in the long term. Regarding overlap of development community, checking quickly I can only find Graham and Ivan being committers here and not in Subversion. (In the PMC, Lieven and Brane are not in Subversion). I don't see a problem with the overlap nor do I see this as a reason to merge. (Unless we can convince Ivan to re-join Subversion, but that is probably another discussion ;-) ). Cheers, Daniel [1] https://infra-reports.apache.org/#downloads&project=serf
