On Wed, May 2, 2012 at 8:11 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Wed, May 2, 2012 at 6:45 PM, Greg Stein <gstein_at_gmail.com> wrote:
>...
>> There is a single open issue that I believe warrants a fix for 1.8, and that
>> is the HTTP/1.0 proxy work. That has been tested with a pre-release build of
>> serf 1.1 for a new API. Before releasing that, I'm waiting on some feedback
>> from Apache OpenOffice, which won't arrive until after they get past the
>> insanity of their release this week. So when 1.1 is released, then I'll
>> enable the code to fix the proxy issue (it's in there, just not
>> fully-enabled).
>
> There is the list of issues on roadmap.html (currently 7 issues). But
> a bit more accurate is simply querying the bug database for
> component==libsvn_ra_serf. That currently shows 17 issues. Definitely
> not all blockers, but certainly more than one (anything that really
> breaks some normal operations, basically).
Yeah... I ran that query after responding. Hadn't seen most of those
other issues. I'll sort 'em out.
>
>>> (not to
>>> mention unkown problems because ra_serf hasn't had enough coverage and
>>> problems aren't always adequately reported).
>>
>> All software has unknown problems. I don't believe there are any more in
>> ra_serf than any other code. If you believe otherwise, then start filing
>> issues.
>
> Sure, sure, we can't fix what we don't know, I get that.
Please understand my frustration. I've wanted to see ra_serf as the
default for years, but nobody steps up to test it. Then we get near
the release and all those people say "not tested", and we kick the can
down the road. Yet Again.
We have to stop kicking it and ship it instead. We ship all kinds of
drastic changes (wc-ng, anybody?). This doesn't even get close to
"drastic", yet there is some irrational fear, and bang... can down the
road again.
>...
>> Because maybe it works? Ever consider that?
>
> Of course that's a possibility. But I sincerely doubt that. It's a lot
> more likely that (ra_)serf, like any software, contains a reasonable
> amount of bugs, some of which will only be discovered by increased
> usage in different environments.
>
> I know it's a bit of a chicken and egg problem (we need more exercise
> so we can find and fix more bugs so we can make it the default so it
> can get more exercise ...). So we definitely will have to "jump"
> someday. All I'm asking is: have we done enough to be sufficiently
> confident to make that jump?
I've been confident for a long time; that's why I use it for
day-to-day work. I don't even have Neon linked in normally. I
configure it in for a test, then remove Neon when I'm done.
It really makes me cranky when people say "not sure about it" when
they haven't tried it, or they did, but didn't file an issue.
(and props to Philip for filing issues against ra_serf)
>>> I think we need some kind of community decision whether or not we'll
>>> go for it this time.
>>
>> When we went with neon for 1.7, we said serf for 1.8. Do you have any
>> concrete information to change that choice?
>
> Well, not really. But it worries me that not much seems to have
> changed between then and now.
Not a lot. The primary blocker that I've been concerned with was the
proxy thing, and that is basically done, pending the serf 1.1 release.
I see these other issues, and can get them handled (fixed, closed,
punted, etc)
> Maybe I'm wrong (certainly some things
> have been fixed/improved, and if you're close to fixing the proxy
> thing, that's definitely a big one). It doesn't hurt to double check
> that we've really got it into good-enough-to-be-default state this
> time, does it?
Sure.
>>> And if we go for ra_serf as the default, put much
>>> more effort into it to make it happen. Starting with agreeing on a set
>>> of requirements that we want to be satisfied before release, or
>>> something like that.
>>
>> Requirements are fixing the 1.8 blocking issues. I say there is just the
>> proxy one, which is mostly done.
>
> And:
> 3981 (serf infinite loop over https)
> 3993 (serf corrupts wc by calling close_edit for an incomplete update-report)
> 4008 (URL-URL copy fails due to "unsupported feature")
> 4088 (assertion failure when using serf instead of neon RA.)
> 4106 (serf checkout fails on XML escaped property names)
>
> (and maybe others, depending on what one considers blocking)
Yeah. Some new ones that I hadn't seen. The 3981 might be fixed; I
seem to recall something in the related code within serf. But in any
case, those sound like blockers on their face.
>...
>>> So I still see ra_serf having a lot of potential, and I
>>> hope it will become the default one day...
>>
>> It is already the default.
>
> Not in any released version.
For *you* and your day-to-day work, it should have been the default
for over two years now.
>...
>> Separately, if you can somehow get me (temporary/occasional) access to any
>> Solaris box, that would be helpful. I have no access to one today.
>
> Sorry, I can't. I can try some things on those boxes if you want, but
> it's pretty limited (I can't even build svn on there, so it's hard to
> try out custom things --- I mostly rely on the CollabNet builds, or
> those from sunfreeware or opencsw etc).
Not a problem. Just figured I would ask. The ASF has a Solaris box,
but I can't access that one either (tho Daniel helped me one day as a
pair of remote hands; that was great).
No real big deal; I might throw out an official query when I think about it.
>...
> Sorry, I was handwaving a bit here. It's not really crashing currently
> (I previously had crashes with serf, but that was with one of the 1.7
> betas I believe, could be the issue you mention was fixed in 1.7). But
> now it's erroring out with "svn: E730053: Error retrieving REPORT
> (730053): An established connection was aborted by the software in
> your host machine." That's with a 1.7.4 client on Windows and a 1.7.3
> server also on Windows.
>
> I'll file a proper issue for this (but not today, it's already past 2 am).
No problem. That is either a server-side problem, or the client
stopped reading the network and the server timed out the request. It
would be useful to look at the server logs for that.
Cheers,
-g
Received on 2012-05-03 03:13:38 CEST