On Wed, Feb 4, 2009 at 2:47 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Feb 03, 2009 at 07:17:34PM -0500, Mark Phippard wrote:
>> On Tue, Feb 3, 2009 at 2:59 PM, Hyrum K. Wright
>> <hyrum_wright_at_mail.utexas.edu> wrote:
>> > This issue has come up a few times on IRC, but I don't know if we've ever
>> > discussed it here, so I'm opening this can of worms now: Should the bindings be
>> > spun off into their own project(s)?
>>
>> I completely understand the sentiment, but I think it is too late to
>> do this (in SVN's history not specifically this release) and could
>> interject a lot of uncertainty into the future of the bindings.
>>
>> We'd basically be asking each of the bindings to come up with their
>> own build systems that had to deal with all the different ways
>> Subversion can be built or packaged. There'd be a lot of uncertainty
>> about whether packagers would include these bindings. As an example,
>> Linux distros have only recently started to really support JavaHL as a
>> package. It used to be really hard to get. I have great fear that if
>> it is spun off it will just get dropped or it will be impossible for
>> something like Subclipse to predict what version will be available or
>> what version of SVN it supports.
>
> As Hyrum pointed out, there are several bindings in existence
> that are being maintained out-of-tree already.
> So this is a solved problem!
Sorry, but bullshit. Just because people like Bert have put in effort
to create bindings does not mean the problem is solved. Someone would
have to recreate all this work for each of the bindings as they
spinoff in their own projects. The stuff Bert did for SharpSVN is not
going to help JavaHL etc. I am not saying the problem is in using our
libraries from bindings, but creating and maintaining a working
development environment.
BTW, I bet that Bert has no desire to move SharpSVN into our project.
He probably likes that he can add features and release on his own
timeline. If I were building Java bindings today, I'd feel the same.
But the bindings have been in the project from the beginning and now
there are tools like Subclipse that exist and depend on them being
consistently delivered along with the core libraries.
>> There is a lot of stuff out there that is built up around these
>> various bindings and this sort of change could wind up creating chaos.
>
> If that was so, then anyone maintaining any kind of code against our
> APIs outside of our tree would wind up in chaos as well.
>
> I think the API stability we provide is all that's necessary to
> successfully maintain the bindings. I'm not a bindings developer,
> so I cannot speak from my own experience. But it looks like there
> are enough examples out there that justify this point of view.
Again, you misinterpret. Our API is fine and if I were building a new
binding today I'd agree. I am saying there is an ecosystem out there
of tools that use our API via the bindings. To suddenly make those
separate could suddenly create chaos for the tools that expected them
to be available.
>> Also, as you touched on, while the bindings can be a PITA it is also
>> hard to know how many release problems they have prevented by the
>> things they uncovered. Things are a little better now because of the
>> buildbot you added. Perhaps this can ultimately help this get better
>> by spotting failures sooner.
>
> That is the only point that concerns me, too. However, nothing stops
> anyone from running any kinds of tests involving bindings against
> our trunk on a regular basis. It's just that it's already set up
> in an in-tree fashion right now. But there is no technical reason
> why this advantage the bindings offer would have to go away if
> they were being maintained out-of-tree.
I think it comes down to timing. If I were maintaining a binding,
odds are I would not be updating it with our trunk on a daily basis.
At best, when we got to a RC phase I'd look into updating them and
only then might I find the problems and be able to report them. We
saw some of this with 1.5 where the problems with the API found
downstream did not show up into right before the final release. The
bindings MAYBE allow us to catch some of these problems sooner.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1103796
Received on 2009-02-04 21:02:40 CET