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

Re: 1.8 Progress

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 30 Nov 2012 10:37:56 +0100

On 30.11.2012 02:15, Gavin Baumanis wrote:
> [...]
>>> 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.
> [GB: ] Hi Everyone,
> I realise I am non-committer to SVN - but am a Software Developer none the less;
> I think it is important - regardless of the route chosen to make a firm decision and stick to it.
> The do we / don't we get rid of ra_neon has been a talking point on here for a really long time now and seemingly still has no "final" status.

Hear hear.

> I'd also like to add, that if the end-game is; we are going to "just" support serf, then surely the answer is to spend time correcting the issues in serf that people have noted, as opposed to spending time re-inserting neon?
> Of course that assumes that we can get serf to where it needs to be - in time for a 1.8 release.
>
> It might just be stating the obvious - but if we can’t get serf to where it needs to be for a 1.8 release of SVN - then surely it is prudent to re-insert ra_neon back into SVN and make 1.9 the goal for being serf-only?

Doing this will make that goal never happen. I disagree with the idea
that Serf is not ready for release for one reason or another. The
important issues all have solutions, and bugs will happen regardless of
how long we wait.

As gstein has said innumerable times, if you don't get people to use it,
it won't get tested. And in the long run, there's no question that the
ra_serf design is superior to whatever we could do with Neon.

-- Brane

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2012-11-30 10:38:37 CET

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.