You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2013/06/03 16:22:41 UTC
Serf issue #102 and 1.8.0 release timing
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: [serf-dev] Serf issue #102 and 1.8.0 release timing
Posted by Peter Samuelson <pe...@p12n.org>.
[Greg Stein]
> But I'll go one step further: you shouldn't care at all.
>
> I could release 1.2.2 tomorrow with all kinds of crap. Or maybe the
> day after 1.8.0 goes final. Not much you can do about it. Subversion
> needs to soak its own code, not the entire dependency stack.
You could, but 1.2.2 would not be the minimum required version of serf.
That makes all the difference. serf 1.2.1 is the minimum requirement
for svn 1.8.0 (well, if you want http+https and digest auth!), so if it
_does_ turn out to be buggy, people can't just fall back on serf 1.2.0
or serf 1.1.0. That is why the question matters: "is 1.2.1 similar
enough to 1.2.0 that a soak in which people were testing with 1.2.0 is
still valid for 1.2.1?"
Re: [serf-dev] Serf issue #102 and 1.8.0 release timing
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Jun 3, 2013 at 10:22 AM, C. Michael Pilato <cm...@collab.net> wrote:
>...
> 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'
>...
> Unfortunately, there is as yet no public Serf release to date which contains
> the fix for this problem.
Released. 1.2.1 is up on Google Code, and messages sent out.
>...
> 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,
Nah. They're fine.
But I'll go one step further: you shouldn't care at all.
I could release 1.2.2 tomorrow with all kinds of crap. Or maybe the
day after 1.8.0 goes final. Not much you can do about it. Subversion
needs to soak its own code, not the entire dependency stack.
Cheers,
-g
Re: Serf issue #102 and 1.8.0 release timing
Posted by Greg Stein <gs...@gmail.com>.
Belay that. I merged a couple extra things in the test suite, and
dropped one (just dealing with fixing a couple compiler warnings).
I'm going to wait for Lieven's +1 before cutting a release.
Cheers,
-g
On Mon, Jun 3, 2013 at 12:53 PM, Greg Stein <gs...@gmail.com> wrote:
> Lieven produced a short list of changes to release in 1.2.1, which I'm
> merging now. The release should be done in about an hour.
>
> Cheers,
> -g
>
>
> On Mon, Jun 3, 2013 at 11:36 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> On 06/03/2013 11:18 AM, Branko Čibej wrote:
>>> I think it's clear that we have to wait for a Serf bugfix release before
>>> releasing RC3, and during that time our soak period is simply on hold.
>>> What happens after Serf 1.2.1 is released depends on the changes there.
>>> If it's just a trivial bugfix for the digest authn issue, then we can
>>> simply continue our soak (of which there are, IIRC, another two weeks).
>>> If not -- then we're faced with a significant change in a non-optional
>>> dependency and I can't think we can wiggle our way out of restarting the
>>> soak in that case.
>>
>> FWIW, I am of the same mind. So far, the 1.2.x branch on Serf contains the
>> following changes made since the 1.2.0 release itself:
>>
>> {{{
>> ------------------------------------------------------------------------
>> r1881 | chemodax | 2013-05-31 09:21:20 -0400 (Fri, 31 May 2013) | 2 lines
>>
>> Merge r1880 from trunk: Fix build with old Windows Platform SDK (issue #100)
>>
>> ------------------------------------------------------------------------
>> r1868 | chemodax | 2013-05-21 06:16:59 -0400 (Tue, 21 May 2013) | 7 lines
>>
>> On 1.2.x branch.
>>
>> Merge r1819 from trunk:
>> SPNego authentication optimization.
>> Justification:
>> Avoid lookup through response headers on every read.
>>
>> ------------------------------------------------------------------------
>> r1865 | lieven.govaerts@gmail.com | 2013-05-20 10:16:16 -0400 (Mon, 20 May
>> 2013) | 10 lines
>>
>> On the 1.2.x branch:
>> Fix issue in serfmake where serf-1.pc is only created when explicitly invoking
>> 'serfmake build', not when going directly to 'serfmake install'.
>>
>> Applied directly to this branch as serfmake was removed from trunk.
>>
>> Patch by: Gabriela Gibson
>>
>> * serfmake: Add .pc file as build target for the install command.
>>
>> ------------------------------------------------------------------------
>> r1864 | lieven.govaerts@gmail.com | 2013-05-20 09:44:26 -0400 (Mon, 20 May
>> 2013) | 8 lines
>>
>> On the 1.2.x branch:
>> Fix issue #95 by applying the patch attached to that issue.
>> Applied directly to this branch as the autoconf build files were removed
>> from trunk.
>>
>> Patch by: Andreas Stieger
>>
>> * configure.in: Add gssapi option to build Kerberos/Negotiate authn module.
>>
>> ------------------------------------------------------------------------
>> r1805 | chemodax | 2013-04-23 12:11:11 -0400 (Tue, 23 Apr 2013) | 2 lines
>>
>> Merge r1804 from trunk: Improve diagnostic of SSPI authentication failures.
>>
>> }}}
>>
>> It's not a great deal of change[1] in terms of code churn, and the fix for
>> issue #102 itself wasn't really all that complicated either. Fortunately,
>> we have the advantage that most of the Serf developership consists of
>> Subversioneers -- so I'll defer the "destabilizing or not" determination to
>> those guys.
>>
>> -- C-Mike
>>
>> [1] svn diff --old http://serf.googlecode.com/svn/tags/1.2.0 \
>> --new http://serf.googlecode.com/svn/branches/1.2.x
>> [2] https://code.google.com/p/serf/source/detail?r=1885
>>
>> --
>> C. Michael Pilato <cm...@collab.net>
>> CollabNet <> www.collab.net <> Enterprise Cloud Development
>>
Re: Serf issue #102 and 1.8.0 release timing
Posted by Greg Stein <gs...@gmail.com>.
Lieven produced a short list of changes to release in 1.2.1, which I'm
merging now. The release should be done in about an hour.
Cheers,
-g
On Mon, Jun 3, 2013 at 11:36 AM, C. Michael Pilato <cm...@collab.net> wrote:
> On 06/03/2013 11:18 AM, Branko Čibej wrote:
>> I think it's clear that we have to wait for a Serf bugfix release before
>> releasing RC3, and during that time our soak period is simply on hold.
>> What happens after Serf 1.2.1 is released depends on the changes there.
>> If it's just a trivial bugfix for the digest authn issue, then we can
>> simply continue our soak (of which there are, IIRC, another two weeks).
>> If not -- then we're faced with a significant change in a non-optional
>> dependency and I can't think we can wiggle our way out of restarting the
>> soak in that case.
>
> FWIW, I am of the same mind. So far, the 1.2.x branch on Serf contains the
> following changes made since the 1.2.0 release itself:
>
> {{{
> ------------------------------------------------------------------------
> r1881 | chemodax | 2013-05-31 09:21:20 -0400 (Fri, 31 May 2013) | 2 lines
>
> Merge r1880 from trunk: Fix build with old Windows Platform SDK (issue #100)
>
> ------------------------------------------------------------------------
> r1868 | chemodax | 2013-05-21 06:16:59 -0400 (Tue, 21 May 2013) | 7 lines
>
> On 1.2.x branch.
>
> Merge r1819 from trunk:
> SPNego authentication optimization.
> Justification:
> Avoid lookup through response headers on every read.
>
> ------------------------------------------------------------------------
> r1865 | lieven.govaerts@gmail.com | 2013-05-20 10:16:16 -0400 (Mon, 20 May
> 2013) | 10 lines
>
> On the 1.2.x branch:
> Fix issue in serfmake where serf-1.pc is only created when explicitly invoking
> 'serfmake build', not when going directly to 'serfmake install'.
>
> Applied directly to this branch as serfmake was removed from trunk.
>
> Patch by: Gabriela Gibson
>
> * serfmake: Add .pc file as build target for the install command.
>
> ------------------------------------------------------------------------
> r1864 | lieven.govaerts@gmail.com | 2013-05-20 09:44:26 -0400 (Mon, 20 May
> 2013) | 8 lines
>
> On the 1.2.x branch:
> Fix issue #95 by applying the patch attached to that issue.
> Applied directly to this branch as the autoconf build files were removed
> from trunk.
>
> Patch by: Andreas Stieger
>
> * configure.in: Add gssapi option to build Kerberos/Negotiate authn module.
>
> ------------------------------------------------------------------------
> r1805 | chemodax | 2013-04-23 12:11:11 -0400 (Tue, 23 Apr 2013) | 2 lines
>
> Merge r1804 from trunk: Improve diagnostic of SSPI authentication failures.
>
> }}}
>
> It's not a great deal of change[1] in terms of code churn, and the fix for
> issue #102 itself wasn't really all that complicated either. Fortunately,
> we have the advantage that most of the Serf developership consists of
> Subversioneers -- so I'll defer the "destabilizing or not" determination to
> those guys.
>
> -- C-Mike
>
> [1] svn diff --old http://serf.googlecode.com/svn/tags/1.2.0 \
> --new http://serf.googlecode.com/svn/branches/1.2.x
> [2] https://code.google.com/p/serf/source/detail?r=1885
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Enterprise Cloud Development
>
Re: Serf issue #102 and 1.8.0 release timing
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 06/03/2013 11:18 AM, Branko Čibej wrote:
> I think it's clear that we have to wait for a Serf bugfix release before
> releasing RC3, and during that time our soak period is simply on hold.
> What happens after Serf 1.2.1 is released depends on the changes there.
> If it's just a trivial bugfix for the digest authn issue, then we can
> simply continue our soak (of which there are, IIRC, another two weeks).
> If not -- then we're faced with a significant change in a non-optional
> dependency and I can't think we can wiggle our way out of restarting the
> soak in that case.
FWIW, I am of the same mind. So far, the 1.2.x branch on Serf contains the
following changes made since the 1.2.0 release itself:
{{{
------------------------------------------------------------------------
r1881 | chemodax | 2013-05-31 09:21:20 -0400 (Fri, 31 May 2013) | 2 lines
Merge r1880 from trunk: Fix build with old Windows Platform SDK (issue #100)
------------------------------------------------------------------------
r1868 | chemodax | 2013-05-21 06:16:59 -0400 (Tue, 21 May 2013) | 7 lines
On 1.2.x branch.
Merge r1819 from trunk:
SPNego authentication optimization.
Justification:
Avoid lookup through response headers on every read.
------------------------------------------------------------------------
r1865 | lieven.govaerts@gmail.com | 2013-05-20 10:16:16 -0400 (Mon, 20 May
2013) | 10 lines
On the 1.2.x branch:
Fix issue in serfmake where serf-1.pc is only created when explicitly invoking
'serfmake build', not when going directly to 'serfmake install'.
Applied directly to this branch as serfmake was removed from trunk.
Patch by: Gabriela Gibson
* serfmake: Add .pc file as build target for the install command.
------------------------------------------------------------------------
r1864 | lieven.govaerts@gmail.com | 2013-05-20 09:44:26 -0400 (Mon, 20 May
2013) | 8 lines
On the 1.2.x branch:
Fix issue #95 by applying the patch attached to that issue.
Applied directly to this branch as the autoconf build files were removed
from trunk.
Patch by: Andreas Stieger
* configure.in: Add gssapi option to build Kerberos/Negotiate authn module.
------------------------------------------------------------------------
r1805 | chemodax | 2013-04-23 12:11:11 -0400 (Tue, 23 Apr 2013) | 2 lines
Merge r1804 from trunk: Improve diagnostic of SSPI authentication failures.
}}}
It's not a great deal of change[1] in terms of code churn, and the fix for
issue #102 itself wasn't really all that complicated either. Fortunately,
we have the advantage that most of the Serf developership consists of
Subversioneers -- so I'll defer the "destabilizing or not" determination to
those guys.
-- C-Mike
[1] svn diff --old http://serf.googlecode.com/svn/tags/1.2.0 \
--new http://serf.googlecode.com/svn/branches/1.2.x
[2] https://code.google.com/p/serf/source/detail?r=1885
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Serf issue #102 and 1.8.0 release timing
Posted by Ben Reser <be...@reser.org>.
On Mon, Jun 3, 2013 at 8:18 AM, Branko Čibej <br...@apache.org> wrote:
> I think it's clear that we have to wait for a Serf bugfix release before
> releasing RC3, and during that time our soak period is simply on hold.
> What happens after Serf 1.2.1 is released depends on the changes there.
> If it's just a trivial bugfix for the digest authn issue, then we can
> simply continue our soak (of which there are, IIRC, another two weeks).
> If not -- then we're faced with a significant change in a non-optional
> dependency and I can't think we can wiggle our way out of restarting the
> soak in that case.
Is there really a reason to pause the soak as opposed to allowing it
to continue and just taking a week on from whenever we produce rc3?
Re: Serf issue #102 and 1.8.0 release timing
Posted by Branko Čibej <br...@apache.org>.
I think it's clear that we have to wait for a Serf bugfix release before
releasing RC3, and during that time our soak period is simply on hold.
What happens after Serf 1.2.1 is released depends on the changes there.
If it's just a trivial bugfix for the digest authn issue, then we can
simply continue our soak (of which there are, IIRC, another two weeks).
If not -- then we're faced with a significant change in a non-optional
dependency and I can't think we can wiggle our way out of restarting the
soak in that case.
-- Brane
Re: [serf-dev] Serf issue #102 and 1.8.0 release timing
Posted by Ben Reser <be...@reser.org>.
On Mon, Jun 3, 2013 at 7:22 AM, C. Michael Pilato <cm...@collab.net> wrote:
> 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.
My vote is to not restart the soak. The plan to wait to produce
1.8.0-rc3 until serf 1.2.1 is available and adjust the dependency
requirements is exactly what I was planning to do.
Given that there's a great deal of overlap in developers with Serf and
Subversion, I trust that the Serf folks can choose appropriate changes
for 1.2.1 that won't be destabilizing.