On Sat, Feb 21, 2004 at 12:06:17AM -0600, kfogel@collab.net wrote:
> 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.
The more I think about it the less I like the idea of a complete
decoupling. I go into the details below.
> 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.
The bindings are not like any other client. They are an implementation
of our API in another language. Treating them like another client of
the API is the problem. Many clients may not use specific features of
the API that we break as we change the API. For example. A client may
not have blame support yet so us changing the blame API wouldn't break
it. Further, it is clearly our intention to start adding more API calls
to 1.1 and beyond to work around API problems. A client will continue
to work with the existing functionality. However, the bindings need to
implement *ALL* the functionality of the C API. If they don't they are
failing to meet their purpose.
I agree with Justin that the bindings should at some point be treated
the same as the C API. In fact doing so would be a great strenth to
this project. Already such important tools as viewcvs depend upon these
bindings. Providing the same compatability guarantees will cause more
applications to be built upon the bindings and will make the subversion
project core even more valuable and useful.
> 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.
Yes for a couple of reasons:
a) API changes have been happening quickly and without a lot of
discussion many times before the changes happening. Without this
discussion the API changes before the bindings developers can say "Hey
you should update the bindings too and here's how"
b) The bindings developers have had a lot of other work to do without
trying to keep up with API changes. We're behind. We've got a lot of
catching up to do.
c) Because we're behind the bindings have not been treated with the same
level of care as the core library.
However, there is precedent for the bindings changes getting done at the
same time. The time API changes happened mostly with appropriate
bindings changes, though some perl changes got missed.
There's no reason we can't do this in the future. API changes from now
on are going to be carefully thought out in order to deal with our
compatability guarantees. This slower pace ensures that there will be
time to do the bindings changes at the same time.
> 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.
It eliminates the ability to treat them as one product. It means the
bindings will always be behind. Which will greatly diminish the
usefulness of the bindings.
By having them in the same tree, when I check out the trunk branch of
subversion, I know I'm getting bindings that should work with that
branch.
In a separate tree we need to separately maintain lines of development.
All the release branching, tagging etc has to be duplicated. This seems
inefficient to me.
Remember, the bindings have to keep up with *EVERY* API change. Not
just the ones that they use. There will never be a circumstance where a
C API change occurrs that doesn't necesitate a bindings change. We'll
have to maintain the same branches as you are.
> So the argument that "the bindings are special" does not convince, at
> least not without further elaboration.
Hopefully I've given that explanation.
> 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.
Once the bindings changes catch up with our 1.0.X API then it shouldn't
be that noisy. For the most part the changes can be happening in the
same commit as a C API change. There will ocassionally be things that
go beyond that, e.g. changes in the language that require some work.
But these languages don't move terribly quickly.
> * Bindings commits show up in the Subversion tree commit emails.
<insert previous answer to your point about the commits showing in the
logs>
But also, if you don't want to see them you can always filter them out.
> * 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...
That's assumes we don't release the bindings at all in the regular
tarball. I kinda like clkao's suggestion of including them in the
regular tarball and then having interim bindings updates. Once we catch
up this probably will be unecessary.
Regarding the voting. This can easily be handled by having the bindings
have their own separate file for voting that lives in the bindings dir.
Then you wouldn't have to see it. Plus if we have the ability to do
interim bindings releases, I don't think there'd be such a rush to do
bindings fixes before a release.
> * 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.
Which is why I like clkao's idea.
> 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.
I think the bindings can't be treated as a separate project. No other
client will ever be as dependent on every little API change or addition.
Plus no client is going to try and keep up with our trunk. rapidsvn
certainly didn't for a long time. The soak time gave them sufficient
time to catch up.
> 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.)
That's simply not true Karl. I found that out the hard way by
ignoring the time API changes. I didn't realize the API was changing
because of that. The perl bindings got bitten in the butt. The only
things I can safely ignore are:
tools, cvs2svn, and packaging.
Everything else I need to pay attention to.
> 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.
Fine so let's have a separate list for binding discussion. I'm not
opposed to that.
> 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 :-).
I also agree with Justin. This is the wrong time to be having this
discussion. I think we should postpone this until the bindings have
caught up with our 1.0.X API and then if you still feel the same way
then review what we should do.
In the interim I'm sure we can alter the mailer.py script to send
bindings only commits to a bindings only commit list to get the emails
about them out of your hair. Create a bindings support/development list
to deal with bindings only issues. This would take a lot of the load
off of you.
--
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 Sat Feb 21 22:56:35 2004