You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2009/02/03 19:59:30 UTC
Spinning off the bindings
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)?
Having the bindings in our tree has its benefits. In the early days of the
project, having a large binding surface encouraged the use of Subversion as a
library, and led to increased adoption. By making the swig bindings officially
supported, users know they can expect a certain quality when they ship with our
releases. Also, the bindings tests (especially the ruby bindings) provide
additional test coverage into our APIs, which helps uncover additional bugs.
However, in the last couple of years, it has seemed that shipping the bindings
with the core libraries has been more of a hindrance than a help. I seem to
recall more than one occasion where a release was held up because the bindings
had problems, and a lack of knowledgeable maintainers[1] led to delays. In
addition to catching bugs, the bindings tests also lead to spurious errors which
can likewise delay development. The root cause seems to be a lack of
maintainers, due to Real Life, lack of interest or otherwise. And shipping
unmaintained code is a Bad Thing: it's better to not ship code than code that is
full of bit rot.
There are already other projects which maintain bindings for languages we do and
don't include, such as SharpSvn, SVNCPP, PySVN and others[2]. Should we follow
their lead and graduate our existing swig and JavaHL bindings into separate
projects? If we did, here are a few questions:
* Where would we spin off the bindings to?
* How much work would be involved in doing this?
* Should/can it be done for 1.6?
-Hyrum
[1] No offense the the existing bindings maintainers, of course. The developer
audience for the bindings is simply smaller than that of the core libraries.
[2] http://subversion.tigris.org/links.html#bindings
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1098250
Re: Spinning off the bindings
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Feb 04, 2009 at 03:30:05PM -0500, Mark Phippard wrote:
> On Wed, Feb 4, 2009 at 3:13 PM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
> > Mark Phippard wrote:
>
> >>> 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.
I just meant that there is no technical reason why this can't be done,
that's all. It's clear that there is work involved.
> > But the bindings are rarely delivered to the end user along with the core
> > libraries. Most *nix distributions put the bindings into separate packages
> > to reduce footprint and dependencies. We even distribute such packages for
> > windows on s.t.o. I posit that the same experience which exists today could
> > be had even if the bindings are in a different package.
>
> I agree that is a possibility. But it is also possible that with
> these bindings spun off as separate projects the distros decide to
> drop them just as we did. It is also possible that the bindings will
> not be available until weeks/months after a release and not make it
> into a distro. It is also possible that the bindings will wither and
> die because no one wants to maintain them on a daily basis and then we
> ship a release the delta is too daunting to bring them up to date.
>
> It is also possible the bindings would flourish as separate projects
> which allowed them to be enhanced on their own schedule and attract
> more maintainers than they have today.
>
> Anything is possible.
Yes.
This morning it occured to me that this discussion might be more useful
if we focused on what would be in it for the bindings and their
developers.
So far, we've mostly argued that the bindings cause problems for the
core developers. But what benefit could spinning off the bindings
bring to bindings developers?
I can't really think of anything, unfortunately, other than the slight
possibility that the bindings would grow into the existing
eco system of out-of-tree bindings (PySVN, PECL SVN, SVNCPP, etc.)
and attract more developers from projects relying on the bindings,
due to the signal that the core devs set by not maintaining them anymore.
But it's equally (more?) likely that people would just lose interest
because of the initial overhead required to repackage things separately,
and because not contributing to the main project anymore could be a demotivating
factor. It decreases visibility of one's work, with visibility of
achievements being one of the primary motivators in FOSS development.
Stefan
Re: Spinning off the bindings
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Feb 4, 2009 at 3:13 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Mark Phippard wrote:
>>> 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.
>
> But the bindings are rarely delivered to the end user along with the core
> libraries. Most *nix distributions put the bindings into separate packages
> to reduce footprint and dependencies. We even distribute such packages for
> windows on s.t.o. I posit that the same experience which exists today could
> be had even if the bindings are in a different package.
I agree that is a possibility. But it is also possible that with
these bindings spun off as separate projects the distros decide to
drop them just as we did. It is also possible that the bindings will
not be available until weeks/months after a release and not make it
into a distro. It is also possible that the bindings will wither and
die because no one wants to maintain them on a daily basis and then we
ship a release the delta is too daunting to bring them up to date.
It is also possible the bindings would flourish as separate projects
which allowed them to be enhanced on their own schedule and attract
more maintainers than they have today.
Anything is possible.
>>>> 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.
>
> I still wonder about this. Again, most people install the bindings via
> their operating system package manager. Heck, if the bindings were
> distributed separately, it might make it *easier* for tools to use them,
> since the bindings have a much smaller footprint and could feasibly be
> shipped with the tool itself.
When JavaHL was immature, I used to long for them to be maintained
separately. So when a SVN feature was not exposed, I could add it to
JavaHL and start using it. Over time, I came to realize that would
not work though.
1) As a consumer of JavaHL, I need a way for my users to get the
library. So I cannot just update it with new features and get that in
their hands. I need to wait for it to flow through the distros.
Let's face it, that is not going to happen quickly.
2) As a maintainer of a fairly complex SVN client, even though the SVN
API is stable and all, I cannot realistically make a client that can
work with any version of the API available. Too much of the UI and
behavior I expose is dependent on my knowledge of how the API behaves.
Could I conceivably condition all my behavior and UI based on the
version I find at runtime? Maybe, but I sure as heck do not want to.
This is not an issue for TortoiseSVN and AnkhSVN because they can
control the libraries the user is using. For Subclipse, partly
because we are cross-platform, we depend on the libraries they have
installed. Anyway, my point here is that I quickly realized that
programming to the "stability" of SVN's release cycle makes my app
better and easier to maintain. If I had to code to a JavaHL that was
maintained on its own schedule, I just could not do it.
>>>> 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.
>
> Only if they are being maintained. If they aren't being maintained, they
> cause more problems due to bit rot than they are worth. And with all due
> respect to Kou and Joe, we've seen this problem with the swig-ruby bindings
> time and again. (I suspect the other bindings would exhibit the same
> problems, were it not for their lack of comprehensive test suites.)
With the same respect to Kou and Joe, and also with some ignorance on
the "details", a problem I see with the Ruby bindings is that one the
one hand, they have a comprehensive test suite, on the other they have
a test suite that is more brittle than the bindings themselves. For
example, they seem to have a test that calls just about every API.
When a new parameter is added to one of our API's the bindings
themselves get updated automatically, but someone has to go into the
Ruby test itself and account for this. This is only a problem during
a release cycle when a new API is evolving, but it seemed to be the
common problem during the 1.5 end-game. I do not have any answers to
this, just that the tests for the Ruby bindings seem to often be the
problem, not the bindings themselves.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1103888
Re: Spinning off the bindings
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Mark Phippard wrote:
> On Wed, Feb 4, 2009 at 2:47 PM, Stefan Sperling <st...@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
>>> <hy...@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.
But the bindings are rarely delivered to the end user along with the core
libraries. Most *nix distributions put the bindings into separate packages to
reduce footprint and dependencies. We even distribute such packages for windows
on s.t.o. I posit that the same experience which exists today could be had even
if the bindings are in a different package.
>>> 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.
I still wonder about this. Again, most people install the bindings via their
operating system package manager. Heck, if the bindings were distributed
separately, it might make it *easier* for tools to use them, since the bindings
have a much smaller footprint and could feasibly be shipped with the tool itself.
>>> 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.
Only if they are being maintained. If they aren't being maintained, they cause
more problems due to bit rot than they are worth. And with all due respect to
Kou and Joe, we've seen this problem with the swig-ruby bindings time and again.
(I suspect the other bindings would exhibit the same problems, were it not for
their lack of comprehensive test suites.)
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1103826
Re: Spinning off the bindings
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Feb 4, 2009 at 2:47 PM, Stefan Sperling <st...@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
>> <hy...@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
Re: Spinning off the bindings
Posted by Stefan Sperling <st...@elego.de>.
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
> <hy...@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!
> 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.
> 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.
Stefan
Re: Spinning off the bindings
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Feb 3, 2009 at 2:59 PM, Hyrum K. Wright
<hy...@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.
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.
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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1099365
Re: Spinning off the bindings
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Feb 03, 2009 at 01:59:30PM -0600, Hyrum K. Wright wrote:
> There are already other projects which maintain bindings for languages we do and
> don't include, such as SharpSvn, SVNCPP, PySVN and others[2]. Should we follow
> their lead and graduate our existing swig and JavaHL bindings into separate
> projects?
I like this idea for the reasons you already stated, and because...
- The bindings sometimes break the build for me, to the point
where I have set up my build environment so that I have to
explicitly call a different Makefile target to build them.
Binding issues are too distracting when working on Subversion core.
I don't know enough about the bindings to fix such issues,
and I don't want to know.
- As the subversion package maintainer for OpenBSD, I have already
inherited from my successor a "multi-package" setup where each
set of bindings goes into a different package, to reduce the amount
of dependencies the main subversion package pulls in.
A few dependencies would be shed off the Subversion core distribution.
- I have recently taken a look at 'svn-load', a very promising candidate
to replace svn_load_dirs (svn_load_dirs lacks a proper licence and
cannot be redistributed by package maintainers). I wanted to import
svn-load into our contrib/ directory. It uses the pySVN bindings,
however, so it would not be usable in our tree out of the box.
So my initial reaction was to put this item on my TODO list:
Port svn-load to swig python bindings and add to contrib/,
update svnbook accordingly, remove svn_load_dirs.pl
If pySVN had the same official status as the swig bindings,
I would not even have spent a thought on porting the script.
Complete waste of time.
Rather, we should encourage more proliferation of binding implementations,
and break down the divide between "official" bindings in our tree and
bindings maintained elsewhere.
- I guess that since our release APIs are stable, the bindings should
not have more difficulty keeping up in-tree than out-of-tree, once the
initial overhead of switching to out-of-tree mode is overcome.
I don't know if people use the bindings against our trunk code at all,
I've never heard of such use (certainly not in production).
> If we did, here are a few questions:
> * Where would we spin off the bindings to?
I'd say wherever the current bindings maintainers want them to go.
> * How much work would be involved in doing this?
Ripping out tons of cruft from the buildsystem (yay!).
Removing bindings-related material from the documentation.
Removing the bindings code and tests from our tree.
> * Should/can it be done for 1.6?
Not sure, I'd wait for opinions of current bindings maintainers
before making such a decision.
One option:
We could decide that for 1.6, we ship the bindings in whatever
state they're in, deprecating them. In 1.7, they won't be
shipped with Subversion core anymore.
Stefan
Re: Spinning off the bindings
Posted by "C. Michael Pilato" <cm...@collab.net>.
Hyrum K. Wright 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)?
>
> Having the bindings in our tree has its benefits. In the early days of the
> project, having a large binding surface encouraged the use of Subversion as a
> library, and led to increased adoption. By making the swig bindings officially
> supported, users know they can expect a certain quality when they ship with our
> releases. Also, the bindings tests (especially the ruby bindings) provide
> additional test coverage into our APIs, which helps uncover additional bugs.
>
> However, in the last couple of years, it has seemed that shipping the bindings
> with the core libraries has been more of a hindrance than a help. I seem to
> recall more than one occasion where a release was held up because the bindings
> had problems, and a lack of knowledgeable maintainers[1] led to delays. In
> addition to catching bugs, the bindings tests also lead to spurious errors which
> can likewise delay development. The root cause seems to be a lack of
> maintainers, due to Real Life, lack of interest or otherwise. And shipping
> unmaintained code is a Bad Thing: it's better to not ship code than code that is
> full of bit rot.
>
> There are already other projects which maintain bindings for languages we do and
> don't include, such as SharpSvn, SVNCPP, PySVN and others[2]. Should we follow
> their lead and graduate our existing swig and JavaHL bindings into separate
> projects? If we did, here are a few questions:
> * Where would we spin off the bindings to?
> * How much work would be involved in doing this?
> * Should/can it be done for 1.6?
>
> -Hyrum
>
> [1] No offense the the existing bindings maintainers, of course. The developer
> audience for the bindings is simply smaller than that of the core libraries.
> [2] http://subversion.tigris.org/links.html#bindings
I've advocated doing this to various degrees over time. I'm not sure
there's a strong reason to spin them off into their own separate projects,
really. At least, no more so than we have reason to spin off our tools/ or
contrib/ directories. The problem is (and has always been) that the
bindings don't have their own release schedules. The solution seems to me
quite simple -- publish them separately (when they are ready to be
published) or don't publish them at all.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1098301
Re: Spinning off the bindings
Posted by John Peacock <jo...@havurah-software.org>.
Greg Stein wrote:
> Well... I haven't seen anybody work on the perl bindings since I
> became active last August. I'd be in favor of disabling them from the
> release.
Is there some overriding reason to disable the Perl bindings, just
because no one has updated them [in years]? They may be stale, but I
just built and tested them on trunk and (at least on my box) there were
no failures.
I wish I had the time to work on the Perl bindings, since they are
something I want to use at $WORK. I spent some time at the last OSCON
with clk talking about how to go about improving the bindings
(supporting the more modern API calls), but I have never had the chance
to do more than scratch the surface.
Personally, I think the use of SWIG is a hinderance, rather than a
benefit, since it means someone wishing to improve the bindings has to
learn both the Subversion API as well as the somewhat cryptic SWIG glue
coding. Maybe I'm just not as smart as I think I am... ;-)
John
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1105251
Re: Spinning off the bindings
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Feb 4, 2009 at 03:19, Bert Huijben <be...@vmoo.com> wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein@gmail.com]
>> Sent: Wednesday, February 04, 2009 2:41 AM
>> To: Hyrum K. Wright
>> Cc: dev@subversion.tigris.org
>> Subject: Re: Spinning off the bindings
>>
>> I think we should integrate them *more*. Get more developers building
>> and running the tests. Right now, they're a second class citizen, and
>> I believe that's a problem.
>
> For some integrations (e.g. Javahl and python) integrating them works great
> as we have quite a lot of developers working on fixing issues on javahl.
> (Javahl is never broken for more than a few hours)..
>
> But who is looking after the ruby and perl bindings?
> Are you volunteering to fix the tests that are broken for (I think) more
> than a week now?
I know nothing about those two, but hasn't Joe been keeping the Ruby
bindings up to date?
Or maybe if the sets of bindings and their tets were part of the
day-to-day build, then somebody would pay more attention to them? Kind
of like "keep stuff on trunk [rather than a branch]". It feels like
the bindings are on a branch.
A long, long time ago, we discussed and decided that the bindings
would be *part* of the product. Part of the functionality that we ship
as "Subversion".
> I'm not planning on fixing a language binding I will never use... A few
> months before breaking the Windows build was taken just as heavy as this
> broken ruby build right now.
Yah. I don't know how to fix any of the bindings, other than *maybe*
the Python bindings. But even then, I haven't looked at those things
for like 6 years.
> I'm in favor for removing the bindings that aren't actively maintained from
> our release process (and if a new maintainer would like that I would be glad
> to help it moving to a separate project with its own release table).
Well... I haven't seen anybody work on the perl bindings since I
became active last August. I'd be in favor of disabling them from the
release. I think we should keep on track and make python (swig and
ctypes), java, and ruby bindings part of the 1.6 release. Then, I'd
suggest that we try the "everybody builds them" to bring them tighter
into the product, and make them much more visible to the developers.
If that doesn't gain any traction for the 1.7 release, then we could
start ripping.
I know that if these bindings and their tests were part of the regular
build, then I'd let that happen and I'd be running their tests. I *do*
think we should have a ./configure switch to disable them, but
(speaking for myself) I would not use them.
> With our ABI guarantees I don't think there is really a need for the
> bindings releasing directly at the same time as the subversion release.
While true, I think they're part of the product, and (therefore) part
of the One True Release Bundle.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1103819
RE: Spinning off the bindings
Posted by Bert Huijben <rh...@sharpsvn.net>.
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: Wednesday, February 04, 2009 2:41 AM
> To: Hyrum K. Wright
> Cc: dev@subversion.tigris.org
> Subject: Re: Spinning off the bindings
>
> I think we should integrate them *more*. Get more developers building
> and running the tests. Right now, they're a second class citizen, and
> I believe that's a problem.
For some integrations (e.g. Javahl and python) integrating them works great
as we have quite a lot of developers working on fixing issues on javahl.
(Javahl is never broken for more than a few hours)..
But who is looking after the ruby and perl bindings?
Are you volunteering to fix the tests that are broken for (I think) more
than a week now?
I'm not planning on fixing a language binding I will never use... A few
months before breaking the Windows build was taken just as heavy as this
broken ruby build right now.
I'm in favor for removing the bindings that aren't actively maintained from
our release process (and if a new maintainer would like that I would be glad
to help it moving to a separate project with its own release table).
With our ABI guarantees I don't think there is really a need for the
bindings releasing directly at the same time as the subversion release.
(But I'm certainly planning on releasing SharpSvn, AnkhSVN and Windows CLI
RC binaries when 1.6 branches.)
Bert
>
> Cheers,
> -g
>
>
> On Feb 3, 2009, at 11:59, "Hyrum K. Wright"
> <hyrum_wright@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)?
> >
> > Having the bindings in our tree has its benefits. In the early days
> > of the
> > project, having a large binding surface encouraged the use of
> > Subversion as a
> > library, and led to increased adoption. By making the swig bindings
> > officially
> > supported, users know they can expect a certain quality when they
> > ship with our
> > releases. Also, the bindings tests (especially the ruby bindings)
> > provide
> > additional test coverage into our APIs, which helps uncover
> > additional bugs.
> >
> > However, in the last couple of years, it has seemed that shipping
> > the bindings
> > with the core libraries has been more of a hindrance than a help. I
> > seem to
> > recall more than one occasion where a release was held up because
> > the bindings
> > had problems, and a lack of knowledgeable maintainers[1] led to
> > delays. In
> > addition to catching bugs, the bindings tests also lead to spurious
> > errors which
> > can likewise delay development. The root cause seems to be a lack of
> > maintainers, due to Real Life, lack of interest or otherwise. And
> > shipping
> > unmaintained code is a Bad Thing: it's better to not ship code than
> > code that is
> > full of bit rot.
> >
> > There are already other projects which maintain bindings for
> > languages we do and
> > don't include, such as SharpSvn, SVNCPP, PySVN and others[2].
> > Should we follow
> > their lead and graduate our existing swig and JavaHL bindings into
> > separate
> > projects? If we did, here are a few questions:
> > * Where would we spin off the bindings to?
> > * How much work would be involved in doing this?
> > * Should/can it be done for 1.6?
> >
> > -Hyrum
> >
> > [1] No offense the the existing bindings maintainers, of course.
> > The developer
> > audience for the bindings is simply smaller than that of the core
> > libraries.
> > [2] http://subversion.tigris.org/links.html#bindings
> >
> > ------------------------------------------------------
> >
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageI
> d=1098250
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageI
> d=1099619
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1099772
Re: Spinning off the bindings
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Feb 4, 2009 at 3:03 PM, Stefan Sperling <st...@elego.de> wrote:
> On Tue, Feb 03, 2009 at 05:40:52PM -0800, Greg Stein wrote:
>> I think we should integrate them *more*. Get more developers building
>> and running the tests. Right now, they're a second class citizen, and
>> I believe that's a problem.
>
> Yes, you are right from a theoretical point of view, but:
>
> I used to build them regularly, but they failed often enough
> that I just stopped to bother. Mail I sent to dev@ about such
> issues would mostly go unanswered for days or weeks. Once, someone
> in the OpenBSD community (note, not from here!) found a fix for a
> bindings problem a couple of weeks after I had already reported
> the issue to our lists (the fix was to upgrade swig to a newer
> version, something I had not tried).
>
> If the maintainers are not active enough so that the bindings unbreak
> quickly, people working on core libraries will natually tend to just
> ignore the bindings during their daily work, because it's too
> distracting.
>
> It's a simple man-power problem, we cannot fix it by asking more
> people to build the bindings and run tests. We need more people
> who know how to fix the problems that keep popping up in the bindings,
> and are willing to do so when the problems pop up.
>
> I don't know how to fix them myself when they break, and so far it
> has not been in my interest to invest the time to learn how to do so.
Keep in mind that until a few weeks ago we did not have any buildbots.
This has always made it a lot harder because you sometimes had to do
a lot of work to figure out the cause of the breakage. At least if we
have the buildbots running the tests we stand a chance on improving
this.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1103817
Re: Spinning off the bindings
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Feb 03, 2009 at 05:40:52PM -0800, Greg Stein wrote:
> I think we should integrate them *more*. Get more developers building
> and running the tests. Right now, they're a second class citizen, and
> I believe that's a problem.
Yes, you are right from a theoretical point of view, but:
I used to build them regularly, but they failed often enough
that I just stopped to bother. Mail I sent to dev@ about such
issues would mostly go unanswered for days or weeks. Once, someone
in the OpenBSD community (note, not from here!) found a fix for a
bindings problem a couple of weeks after I had already reported
the issue to our lists (the fix was to upgrade swig to a newer
version, something I had not tried).
If the maintainers are not active enough so that the bindings unbreak
quickly, people working on core libraries will natually tend to just
ignore the bindings during their daily work, because it's too
distracting.
It's a simple man-power problem, we cannot fix it by asking more
people to build the bindings and run tests. We need more people
who know how to fix the problems that keep popping up in the bindings,
and are willing to do so when the problems pop up.
I don't know how to fix them myself when they break, and so far it
has not been in my interest to invest the time to learn how to do so.
Stefan
Re: Spinning off the bindings
Posted by Greg Stein <gs...@gmail.com>.
I think we should integrate them *more*. Get more developers building
and running the tests. Right now, they're a second class citizen, and
I believe that's a problem.
Cheers,
-g
On Feb 3, 2009, at 11:59, "Hyrum K. Wright" <hyrum_wright@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)?
>
> Having the bindings in our tree has its benefits. In the early days
> of the
> project, having a large binding surface encouraged the use of
> Subversion as a
> library, and led to increased adoption. By making the swig bindings
> officially
> supported, users know they can expect a certain quality when they
> ship with our
> releases. Also, the bindings tests (especially the ruby bindings)
> provide
> additional test coverage into our APIs, which helps uncover
> additional bugs.
>
> However, in the last couple of years, it has seemed that shipping
> the bindings
> with the core libraries has been more of a hindrance than a help. I
> seem to
> recall more than one occasion where a release was held up because
> the bindings
> had problems, and a lack of knowledgeable maintainers[1] led to
> delays. In
> addition to catching bugs, the bindings tests also lead to spurious
> errors which
> can likewise delay development. The root cause seems to be a lack of
> maintainers, due to Real Life, lack of interest or otherwise. And
> shipping
> unmaintained code is a Bad Thing: it's better to not ship code than
> code that is
> full of bit rot.
>
> There are already other projects which maintain bindings for
> languages we do and
> don't include, such as SharpSvn, SVNCPP, PySVN and others[2].
> Should we follow
> their lead and graduate our existing swig and JavaHL bindings into
> separate
> projects? If we did, here are a few questions:
> * Where would we spin off the bindings to?
> * How much work would be involved in doing this?
> * Should/can it be done for 1.6?
>
> -Hyrum
>
> [1] No offense the the existing bindings maintainers, of course.
> The developer
> audience for the bindings is simply smaller than that of the core
> libraries.
> [2] http://subversion.tigris.org/links.html#bindings
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1098250
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1099619