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

Re: handling bindings changes for 1.0

From: Ben Reser <ben_at_reser.org>
Date: 2004-01-09 02:46:46 CET

On Thu, Jan 08, 2004 at 04:32:53PM -0600, kfogel@collab.net wrote:
> Should we abandon the three +1's system for bindings changes on the
> 1.0 branch?
>
> We already agree, it seems, that the bindings do not have to be of
> "1.0 quality" to be in 1.0, and that we just want to ship the latest
> of whatever we have. In that case, the standard review process shold
> be fine. That is, anyone who could commit to bindings on trunk can do
> so on the 1.0-stabilization branch too, with the understanding that
> the 1.0 commits should (of course) match the API on that branch, and
> that this is not the time to go adding new features to the bindings
> for 1.0 :-).
>
> Thoughts?
>
> If people would like to move to this system, I can adjust the STATUS
> file accordingly.

Well my long standing concern has been the difficulty in finding people
who understand the bindings enough that they're willing to give a +1 to
the changes. At least on the perl end there's probably only clako who
really indepth understands them (and me but I don't have a vote). epg
voted for the changes in the STATUS file on perl, so I'm assuming that
he felt comfortable voting on it, but I'm unsure of what his experience
is with them. dionosis and rooneg seem interested in them but I'm not
sure how familiar or comfortable they are with voting on them. The
javahl votes seem pretty scarce as well. Granted you decided that
bindings votes didn't need to be finalized.

I'm not convinced there are enough people who are terribly familiar
enough with the bindings to be casting +1s for things on them. At the
same time I would love to have them reviewed as much is as possible.
I'd just assume not ship bugs.

As I said earlier on IRC I'm not sure what you mean by "features." The
bindings are just that (at least as far as the perl ones go) bindings.
They provide binding between the C API and the language they're
implementing it to.

Sure they hide things like passing in a pointer to a function call as a
place to place an output. But then again perl doesn't really provide a
construct that fits that.

If you're going to qualify as making sure the methods work as "features"
I'm going to protest loudly. As I said previously there are still
several methods in the perl bindings that are untested. Given your
schedule there's no reason why I can't take and finish them up. I
suspect there's only minimal work to be done anyway.

IMHO the bindings should implement as much as the API as we possibly can
at 1.0 release.

-- 
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 Fri Jan 9 02:47:20 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.