Justin Erenkrantz <justin@erenkrantz.com> writes:
> I have an issue with moving the development of the bindings out of
> dev@svn, but I definitely don't have an issue with the bindings being
> separately released though from the core. However, the bindings are
> *extremely* tied into the core - in a way that no other SVN
> applications would be. In the long run, I think it'll be beneficial
> to have them joined together not artificially separated.
The main thing I'm talking about, in addition to the bindings being
released in a separate tarball(s), is that they also get moved out of
the Subversion repository. That is, I think they should be treated
like any other third-party project. Having reviewed emails & thought
a bit more, I also think they should have their own mailing lists.
So yes, this proposal is for a complete decoupling.
In practical terms, I don't see why the fact that the bindings are so
tied to the core APIs makes it somehow necessary for them to live in
the same tree. If someone could explain why it matters, with concrete
examples, that would help. So far, the best argument I've heard (in
irc) is that someone can commit a core change and its corresponding
bindings change in a single revision. Well, yippee! :-) Not only is
this not a terribly compelling advantage, the truth is it almost never
happens right now anyway, so we wouldn't be losing it.
When I think of exactly how the bindings development process would
work as a separate project, I don't see how them being in a different
tree would interfere with that process.
So the argument that "the bindings are special" does not convince, at
least not without further elaboration.
> I think cvs2svn can easily be split off as there is a clear
> demarcation line, but I just don't see the same rationale for the
> bindings.
Here are some rationales:
* Bindings commits show up in the regular Subversion log history.
This is noise. We have to skip over it when generating the
CHANGES file -- or, worse, pay attention to it. IOW, there's one
more burden for people browsing logs, for whatever reason.
* Bindings commits show up in the Subversion tree commit emails.
* Bindings votes occupy a large portion of the activity in STATUS
files right now. One might respond: "Yes, but we're proposing
that they be released separately, so that won't be a factor."
Sure, but read on...
* It's confusing to have bindings in the regular tree yet not
include them in packaged SVN distributions. It implies a greater
difference than currently exists between tarballs and working
copy builds, because someone building from a working copy faces
the question: do I use the bindings here, or get the released
bindings package? Theoretically, you should use the bindings
right there in the tree, because they'd be most up-to-date for
that code. Yet this is the opposite of the way the user should
behave for tarball builds, where the bindings won't even be
present in the tree. Confusion reigns.
The more simple and comprehensible solution is: if something that
is used with Subversion is nevertheless not distributed with
Subversion, that that something shouldn't live in Subversion's
tree either.
* We tried once keeping other projects in the same repository as
Subversion (the old clients/ dir). We hated it. We stopped.
"Those who forget history are condenmed to repeat it." :-)
* Third-party clients are intimately tied to our APIs too, and have
often been bitten by API changes. Yet they've managed just fine.
Please note that the issue is not the importance of the bindings.
They're very important, but that's not relevant here. The more
popular third-party clients are also very important, but we don't keep
those in our tree.
The important factor, IMHO, is that the bindings developers are, by
and large, different from the C code developers. *Most* discussions
the C developers have are not relevant for the bindings developers,
and *most* discussions the bindings developers have are not even read
by many C developers. (Sure, there's some crossover, I'm just talking
about the broad view here.)
What keeps the bindings up-to-date is not their proximity on disk to
the core API files. It's humans -- humans building and using the
bindings, and discovering problems. Humans will be no more nor less
able to do this with them as a separate project. The difference is
that when people *do* discover problems, they will have a more focused
forum for solving them, and not distract others who for the most can't
help them anyway.
As you can tell, I feel pretty strongly about this. I really, really
want those bindings to have the status of a full, separate project,
with all the rights, privileges, and responsibilities thereunto
appertaining :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 21 08:08:57 2004