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

Re: Spinning off the bindings

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 4 Feb 2009 21:12:07 +0100

On Wed, Feb 4, 2009 at 03:19, Bert Huijben <bert_at_vmoo.com> wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein_at_gmail.com]
>> Sent: Wednesday, February 04, 2009 2:41 AM
>> To: Hyrum K. Wright
>> Cc: dev_at_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.


Received on 2009-02-04 21:12:51 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.