On Wed, Jan 25, 2012 at 13:05, Daniel Shahaf <danielsh_at_elego.de> wrote:
> Daniel Shahaf wrote on Wed, Jan 25, 2012 at 19:26:33 +0200:
>...
>> Same fix to ra_neon please?
>>
>> svn_ra_neon__open()
>
> Greg replied on IRC --- basically that he won't maintain ra_neon and
> thinks that library should be given a one-way ticket to the bit bucket.
> (Greg --- if I'm misrepresenting your position, please correct.)
Yup. That's my view. ra_neon is a dead end. In some discussions with
Hyrum about Ev2 this week, there are some aspects to improving 'svn
update' that I don't think ra_neon will be able to handle. There are
things we can do to improve commit that ra_neon cannot do (let alone
the future parallel-PUT capability). ra_neon is a boat anchor to
making network improvements.
There are a couple minor ra_serf bugs in the issue tracker to wrap,
but ra_neon should go.
> Last I checked, ra_neon was still a supported RA layer and therefore
> I believe it should still get TLC --- bugfixes and new features.
> (Including the above trivial fix.)
Trivial *only* if you have a set up to test the result. I don't. So it
isn't a "trivial" fix for me.
eg. track down the code in ra_neon; examine whether it parses the same
or not; update the code; figure out flags and proper neon lib;
reconfigure my client; wait for the full rebuild; run some tests
against servers with different certificates; write log message and
commit; reconfigure back to serf-only; full rebuild.
> Alternatively, what stops me from implementing my new features only
> implementing them over ra_local and ra_svn, claiming that I think both
> DAV layers should be memset(0)-ed?
Because as a project we want local, svn, and dav. If you don't have
the inclination or environment to test dav, then I'm sure that
somebody else will step in to do the work.
Shoot. I rarely am prepared to do dav or svn testing. I do my work and
testing over local.
I don't have a Windows box. I do my work on Mac OS.
Long, long ago, as a project, we decided to "do the work as you are
able; each developer is not responsible for all potential variants and
platforms".
Back to the RA case you mention: if you added a new RA API and didn't
even get the other RA layers to compile, then we'd have a problem and
I would expect somebody to apply a veto until the project at least
compiled. If you added the RA entrypoints, but didn't implement them
for all the RA layers, *and* they became non-optional (ie. the RA
tests immediately started failing on the buildbots), then I'd expect
to see the change moved to an #ifdef to make it optional or move it to
a branch. You'd effectively be disabling trunk from doing 'svn co
http://svn.apache.org/...'.
Case in point, CMike implemented HTTPv2 only for ra_serf. That was no
problem because it wasn't required for ra_neon. Later on, he found
time and interest to add the functionality for ra_neon. No skin off
anybody's back for his approach.
If you find the parsing fix for ssl-authority-files to be important
for ra_neon, and you're comfortable changing it without testing, or
you have a testing environment for it, then please go ahead. I don't
find it personally important, and I don't have an environment (and I'm
uncomfortable with *not* running a simple test), so I declined to make
the change. If it was a bug fix rather than (IMO) a cosmetic fix, then
I may have taken the time. But whitespace parsing on something that I
doubt has ever been reported... nope.
I understand you didn't like my response of "I don't want to fix
ra_neon". Maybe you found it flippant. Maybe you disagree with my
explanations above, of my thoughts and (at least, historically)
project culture. But I'm really not sure how to better answer you.
Cheers,
-g
Received on 2012-01-26 02:02:32 CET