[I'm going to try to summarize the body of responses generated from this
original query -- a conversational reset, if you will -- so as to keep this
line of inquiry moving toward closure.]
On 11/01/2012 02:42 PM, Ben Reser wrote:
> Looking at our roadmap we have the following things still in progress:
>
> 1) local moves/renames. Based on the conversation I had on IRC this seems
> to be not done yet due to issues found in the original plan. stsp says that
> if it can't be done before we want to otherwise release 1.8 he'd like to
> pull the move code entirely. So the question here is do we wait for some
> unknown amount of time for this to complete? Is this an important 1.8 feature?
Philip sez: "I'd like to get this in. The local-move/incoming-edit stuff
is not a huge task, I think we could get it working before the end of the year."
Stefan Sperling later responded (in another thread): "Well, I'm starting to
think that we underestimated the size of the problem (again, as we did in
1.6), and should probably try to find a correct design before writing more
code for this (except maybe XFAILing tests). Which means we should be
prepared to pull the moves feature from the 1.8.x branch once it is
branched, since move tracking doesn't provide any benefit if moves cannot be
updated properly. I don't think we can get this done before 1.9..."
I also seem to recall Stefan also saying something about not having time to
work on this stuff for the remainder of 2012, but I can't find a reference
for that at the moment, so perhaps I just misremembered.
OWNERSHIP: Given Philip's comment, I believe it is reasonable to deem him
the owner of this body of work, or at least co-owner with a
possibly-time-constrained Stefan. But perhaps all there is to "own" is the
post-branch removal of the feature?
> 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?
Julian expressed doubt about whether the API was ready for prime-time.
C-Mike expressed concern about the extremely low bus factor.
Hyrum acknowledged both, and continued with: "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."
OWNERSHIP: Hyrum's got the most experience here, but due to his time
contention, we may very well have no owner for this at all. That's bad.
> 3) libsvn_ra_serf stabilization. I know there have been a couple concerns
> that Philip has raised (EAGAIN and the random failures).
Philip and Ivan both seem keen on reinstating ra_neon.
Justin poopooed the idea of reinstating ra_neon simply to get 100% feature
coverage, suggesting that the way forward for the believed-to-be-small
fraction of folks depending on Neon-specific features is to just stick with
1.7. (Not sure how serious he was.)
Mark expanded the scope of the discussion to include Serf's affect on
servers (growth of server logs, expanded number of server connections, etc.).
Lieven, in a neighboring thread
(http://svn.haxx.se/dev/archive-2012-11/0225.shtml), enumerated a number of
specific observed problems with ra_serf:
> 1. When a very low Timeout is set in the apache server configuration,
> the server truncates response bodies in some situations
There appears to be a fix for the more egregious of these situations
in serf already, but Lieven indicated he'd look into this one.
> 2. ra_serf consumes way too much memory while doing large checkout's
> (issue #4196).
I believe I've finally fixed this with my commits to ra_serf on trunk
this week.
> 3. Ivan added a potential issue because ra_serf+serf are not handling
> events on each open connection regularly. This can result in timeouts,
Ivan submitted a patch for a portion of this work
(http://svn.haxx.se/dev/archive-2012-11/0193.shtml), but either way
it's not clear if this problem is theoretical only or has been observed.
> 4. Ivan further observed that the spillbuf mechanism, used to keep
> ra_serf reading from the REPORT connection while waiting for slow disc
> i/o, has two drawbacks:
> 4a. the amount of data stored in the spillbuf can get very large
> when processing the REPORT response is paused. When resuming, all
> data in the spillbuf is read and processed in one go. As this can
> be 1MB+ it can take a while, potentially timing out the REPORT
> response connection -> svn will stop.
> 4b. The GET and PROPFIND requests resulting from parsing that big
> chunk of data will all be sent on the same connection, where we
> have 4 available to send more requests in parallel.
(I've nothing to add to this.)
> 5. In one of Philip error-reporting mails, there was mention of a "408
> Request Time-out" response. (http://svn.haxx.se/dev/archive-2012-11
> /0076.shtml).
This was ultimately logged as a bug in the Serf project:
https://code.google.com/p/serf/issues/detail?id=91
OWNERSHIP: I can claim ownership of the ra_serf side of things if Lieven
and Ivan (or others) can step up to advise me and to cover the Serf part
itself. As for the reinstatement of Neon, I believe we need to make this
decision very soon. If we choose to reinstate, I'll claim ownership of that
task, too (post-branch).
> 4) Symmetric merge. Should be done per julianf.
Yay!
> 5) Inherited properties/Server-dictated configuration. This is marked as
> completed but I see some discussion over property names still ongoing.
This is also complete.
> 6) Conflict storage. This is marked as done but there was discussion in the
> past about needing a wc format bump? Where are we with that?
This garnered no response.
OWNERSHIP: Bert? (And is it finished for 1.8 already?)
> 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).
Yes, Paul has done the test review, and he and I have been sort of triaging
issues incrementally and as time allows.
> 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?
This is completed. We now require manual upgrade, per the work Stefan
Sperling did subsequent to this thread.
> In particular I'd like to see the outcome of the thread be that we have some
> idea what work we feel remains and who is going to be doing it.
We still kinda lack well-defined ownership for some of these things. See above.
> 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.
As I indicated previously, it's one thing to "rush" a new release, and
another to do good by our users by not delaying releases indefinitely.
Of interest to me as I scanned this thread and others was the lack of new
initiatives folks are declaring as 1.8-must-haves. I believe that it's only
with a firm target in view that we'll ever be able to make the necessary
go/no-go calls that will govern what this release will ultimately look like.
So with that in mind, I'd like to suggest that we consider setting for
ourselves a goal of branching for 1.8 stabilization by the end of the
calendar year.
Thoughts? Updates to the aforementioned status reports/summaries?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-11-29 22:52:53 CET