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

Re: Moving bindings into a separate project.

From: Ben Reser <ben_at_reser.org>
Date: 2004-02-24 20:06:47 CET

On Sun, Feb 22, 2004 at 03:59:27AM -0800, Brian Denny wrote:
> Most of what you say makes sense to me, Ben, but...
>
> "The bindings". There's an awfully large set of potential language
> bindings out there. Which ones are 'essential'? Right now it seems
> easy to answer that question: the small handful that are fairly
> well-developed already. But what about down the road? What if a couple
> of people get the Ruby bindings together and caught up with the C API?
> Do those then become 'essential' too? Is there a limit to the number of
> bindings that can be considered 'essential', given that each one then
> carries the risk of holding up a release?

Well I was mostly talking about javahl, python and perl. Though I
suppose I could have been more precise. What's an essential binding?
I'd say we'll find that out after seeing how people use them. If we
don't see any projects using a binding set it's probably a big sign that
it isn't essential. But I think it's really too early to say which ones
are essential. Cases can made for various existing bindings at this
point. But I'm not sure we really have the experience to call any of
them essential yet or for that matter non-essential.

As far as adding bindings. I'm sure if the issue comes up we can deal
with it. I'm tempted to say that new bindings could be built up outside
our tree to match our API and then merged in. At least that's an option
if we want to avoid the noise of a new binding. But it really all
depends on what our goals are.

> If a set of 'essential' bindings falls behind, do we try to enforce
> developer interest? Hold up core svn indefinitely? (After all, if it's
> essential, then it *is* core svn, right?) Or do we at some point bite
> the bullet and say that it can't be 'essential' if folks aren't
> willing/able to keep it up to date?

I'd say the latter. If something is going to hold up a release then
it's probably not anything we can call essential. (Yes that means I'm
committed to maintaining the perl bindings).

> I guess that's where the 'it's too soon to be having this discussion'
> comes in. I definitely see your point that things are going to be a lot
> less chaotic, API-wise, after 1.0. So now is too soon to judge whether
> folks are willing/able to keep the bindings up to date.
>
> Still it's important to think about the limits of what gets called
> essential. Every new 'essential' thing adds a maintenance burden.

Sure, but we also need to remember that this is a collaberative project.
Full committers don't have to do everything. And the more users there
are of subversion (and the bindings) the bigger the pool is of people
willing to maintain them.

We're now at 1.0. For whatever reason a lot of people have avoided
playing with subversion till now. I don't think we know what our pool
of available developers is. Right now we have the original developers
and early adopters. Which is another reason that this is the wrong time
to be having this discussion.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 24 20:06:24 2004

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.