[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Serf issue #102 and 1.8.0 release timing

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Mon, 3 Jun 2013 10:22:41 -0400

Last week it was discovered that Serf 1.2.0 broke support for Digest
authentication, at least for applications such as Subversion where a
connection might be used for multiple requests against different URLs. You
can read about the problem in the issue where it was tracked (Serf issue
#102 [1]) and in supporting sources.

The problem has been fixed, thanks to Lieven's immediate and timely
attention and efforts. The question for us is: does this constitute a
soak-restart-worthy bug, and if so, on whose timeline?

On the one hand, it's trivial to argue that the bug wasn't Subversion's at
all, therefore can't force us to restart our soak period.

On the other hand, Serf 1.2.0 is the only available public Serf release with
which Subversion 1.8.0 can operate[2], which really rather limits folks'
ability to work around issue #102. From the end user's perspective, it's
going to be, "Subversion 1.8.0 doesn't work with my server" -- little
details such as which library is to blame and which authn mechanism is in
use are of little to no interest at all.

Unfortunately, there is as yet no public Serf release to date which contains
the fix for this problem. This means that were we to release Subversion
1.8.0 today, we'd have to do so with a warning label that informed folks
about the Digest auth deficiency. And I'm not even sure how useful that
would be -- *I* certainly couldn't tell you based on my typical userland
Subversion interactions which of the servers I interact with daily use
Digest auth and which use something else.

What, then, is the approach that best serves our users?

I'll suggest that the answer is found in how we'd track the issue locally.
"Subversion requires Serf 1.2.1" would be a reasonable issue description.
It would naturally be a 1.8.0 blocking issue. It's resolution (on our end,
at least) would be simple -- some build system twiddling is all. What
remains, then, is the determination of whether those changes (and it is
arguably fair to consider all the changes made between Serf 1.2.0 and 1.2.1,
here, too) are destabilizing or not. If they are considered destabilizing,
we're at least release_date(serf_1.2.1) + 28 days away from 1.8.0-final
again. If they are not, then we should hold off on 1.8.0-rc3 until Serf
1.2.1 is produced (hopefully Real Soon Now), and then our final release can
come a week after that.

Thoughts?

-- C-Mike

[1] https://code.google.com/p/serf/issues/detail?id=102
[2] See also: http://subversion.tigris.org/issues/show_bug.cgi?id=4274

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2013-06-03 16:23:18 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.