On Thu, Nov 1, 2012 at 3:11 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 11/01/2012 02:42 PM, Ben Reser wrote:
>> 2) Ev2. The notes say this is believed to be in a releasable state? Is
>> there any work needed to verify this? Do we need to remove the use of Ev2
>> in any place to avoid releasing with compatibility shims in use? Are we
>> comfortable that the API is complete?
>
> Honestly, I'm a bit concerned that with Hyrum and Greg both effectively
> inactive, Ev2 runs the risk of appearing in our public API without any
> remaining active champions/implementors/maintainers of it. There's a
> non-zero fear factor here.
Understandably so. I've been trying to leave breadcrumbs and beg for
help over the past several months, but nobody has taken me up on it.
I've been hacking around on Ev2 as I can, but Real Life is leaving
little time for that these days. I can consult, direct and review,
but my hacking time is very limited.
We can always shuffle headers around or document the things as
experimental, so committing ourselves to the API as this point isn't
my concern. The only real limiting around Ev2 and 1.8 is issue #4116
which is svnrdump failures over ra_serf. In the issue, I propose
using Ev2 to get around the problem, since the dumpfile format is so
incongruent with the editor.
Of course, we don't *have* to do that, but as I've thought about it,
any solution will require a bit o' caching---which we've already
implemented as part of the Ev2 shims. We *might* be able to implement
the svnrdump editor as Ev2, shim the thing on the client side (which
gives us the required caching) and release that way. Or there might
be a better solution I'm overlooking because I've got Ev2 on the
brain.
>> 3) libsvn_ra_serf stabilization. I know there have been a couple concerns
>> that Philip has raised (EAGAIN and the random failures). Plus there are
>> several issues here (not all of the issues here are serf
>> issues):
>>
>> Who can drive these issues to completion? Is there any additional testing
>> work we should do to try and determine the stability of serf in light of
>> the fact that we're planning to remove neon?
>
> I've been steadily working on the ra_serf stuff, but there are some issues
> which appear to need some deeper focus by members of the Serf dev-team.
> Lieven mentioned a bit ago that he was planning to invest a block of time
> here soon (ApacheCon Europe hackathan, perhaps it was?) -- I'm hoping we'll
> see some significant progress on ra_serf stabilization as a result.
>
>> 5) Inherited properties/Server-dictated configuration. This is marked as
>> completed but I see some discussion over property names still ongoing.
>
> To the best of my knowledge, it's only this superficial property name
> discussion that's still unresolved.
>
>> Beyond that we have the ordinary reviews of tests (pburba has said he's
>> working on this), new apis and issue triage (cmpilato seems to have been
>> doing some issue triage).
>>
>> Also at the risk of opening a can of worms we need to decide on the wc
>> upgrade issue? I can say that the impression I got from Subversion Live was
>> that a lot of people use multiple clients and that auto-upgrade seems bad.
>> But we also discussed trying to handle reads from an older wcng style wc
>> without requiring a wc upgrade. Can someone drive this?
>
> I distinctly recall stsp offering to take up the charge on this. :-)
>
>> Lastly I don't want to give the impression that I'm rushing 1.8. However, I
>> would like us to see us focus on the things we want to get done with 1.8.
>
> Rushing 1.8? No, that's not this community's style. But I'm starting to
> see feedback from our user base that the slippage we've allowed in the
> release already is not inspiring confidence. I'm trying to keep my focus on
> 1.8. There are plenty of other things I'd love to get my fingers into
> (FSv2, master passphrase, etc.) but at some point we need to remain good
> stewards of our user base.
+1, and I'm sorry I can't help more.
Received on 2012-11-02 02:42:29 CET