Ben Reser <ben@reser.org> writes:
> So in summary. I'm fine with 3 +1s for binding updates. I do think we
> should be a little more flexible on what we merge in for the ones that
> are incomplete. But by more flexible I don't think automatic approval
> is the answer either. I just think they shouldn't necessarily be held
> to the standards that we would hold the C API too regarding not making
> major changes. I don't see any way to get them up to snuff without
> making some major changes.
Let's see what the changes look like and then decide.
After all, they have to be made eventually, if not for 1.0, then for
trunk leading to the next major release. So the work won't be wasted.
We can't have a policy of holding up major releases until all bindings
are ready. The set of bindings is ever-increasing, and yet has fewer
developers paying attention to it than the core code, so blocking on
bindings is a recipe for delay.
Nevertheless, we can still make an effort not to ship with broken
bindings, if the changes look good. Let's not decide in the abstract,
let's decide based on the changes themselves.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 19 18:10:47 2003