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

Re: Moving bindings into a separate project.

From: <kfogel_at_collab.net>
Date: 2004-02-23 00:53:03 CET

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.

Thank you,

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 23 01:55:54 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.