On Wed, Jan 25, 2012 at 13:05, Daniel Shahaf <danie...@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
