Some people have posted to say that they want the bindings to be
considered part of "core" subversion.
I wish it were that easy. But in reality, it's been a noticeable
burden, and treating them more "core-y" would be an even bigger
* It's too hard to keep the bindings up to date in realtime -- I
would think no more evidence than the past year need be offered
in support of this assertion! Yet if they were decoupled, the
bindings would no longer have to track a moving target at the
same rate as the target. They would simply have to track
releases of Subversion, with whatever degree of responsiveness
can be mustered.
* There is no consensus among the developers for treating bindings
breakage as seriously as core breakage. Justin, you may have
envisioned that as an immediate post-1.0 goal, as you said in
your earlier mail, but many of us aren't willing to add that to
our dev & testing burdens. I'm a solid -1 on ever making
bindings maintenance part of core responsibilities (in the sense
that keeping the core code regression suite passing is part of
core responsibilities, for example).
* The bindings interfere a *lot* with releases -- I've been
intimately involved in several releases in a row now where the
majority of our voting time, review time, and general release
headache time has been spent on bindings. Enough is enough,
* ... as useful as the binding are, they are _not_ essential in the
same way as Subversion itself.
* And if they are not to be released with Subversion, they should
be decoupled into a third-party project (rationale given in an
earlier post in this thread.)
What I feel is still missing in this conversation is a concrete
example of how decoupling will make bindings maintenance more
difficult. I think it will make it *easier*, because the set of
targets becomes just the set of released Subversions.
I'll agree that decoupling and shipping separately *does* raise the
bar to using the bindings, slightly. But how hard is it, really, to
add a line to the release announcement for 1.1 saying that the
bindings are now shipped separately, and telling people where to look
for them? And for the recipients, is it *really* so hard to download
and build another tarball for this functionality?
Sure, it's a bit harder. But don't discount the current burden on
developers. *All* users of Subversion, including those who never use
bindings, are paying the price of that burden.
And please, don't accuse anyone of turning this into an "us vs them"
kind of thing. That's the tech mailing list equivalent of a
politician challenging his opponent's patriotism -- we can do better
than that here, I think :-). My goal is to make things easier for the
project as a whole. What this means in practice is going to be
debatable, because not everyone has exactly the same goals. This fact
of life can be acknowledged without being divisive.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Feb 23 01:55:54 2004