Re: Moving bindings into a separate project.

Justin Erenkrantz wrote:

> --On Friday, February 20, 2004 11:44 AM -0600 kfogel@collab.net wrote:
>
>> I'd like to get the language bindings out of the core Subversion tree
>> and into their own project.
>
> ...
>
>> I think life will be *much* easier for both core Subversion developers
>> and bindings developers if we do this.
>>
>> Any objections?
>
>
> 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.
>
> 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.
>
> Am I alone? -- justin

You're not
/me to the rescue

I think moving bindings out to a separate project would be a mistake for
at least two reasons:

    * A lot of our markethype is about how easy it is to use and script
      the SVN libraries. Pulling the bindings out of the core project
      would suddenly give a totally different message: "Here are the
      libraries, if you use C, then fine, otherwise the Subversion
      project isn't interested in you." Note that bindings are in a
      completely different league than clients/GUIs, because they are
      _perceived_ as being more tied to the core (even though the
      connection is no deeper than for a client). In that light, I'd
      rather go the opposite way and suggest moving the C++ wrapper
      _into_ the core project.
    * Many of our examples and tools rely on the Python bindings. Do we
      move mailer.py out of the core project with the bindings? I don't
      think so.

Instead of washing our hands of the bindings, we should impose similar
quality standards as for the core code -- the bindings need their own
tests, which must pass on at least one platform before a commit to the
bindings code (or related build scripts).

As for releasing the bindings separately: really, how often will we make
releases? The days of 2-week release cycles are, I hope, over. Changes
to the bindings on the 1.0.x branch will be for bugfixes only, as there
can be no API changes. Treating the bindings as second-class citizens
made a certain amount of sense for 1.0, because it was the only sane way
of getting the release out the door. But I see it as being a temporary
fix for covering the earlier mistake of not requiring the bindings to
meet the same quality standards as the rest of the code, as I said
above. I propose we change this policy and take the time from now to
1.1.0 to make the bindings toe the line.

Indeed, this means that Subversion can no longer be the fun trip it's
been until now; we'll have to institute the office of maintainership
(and not just for bindings, either). On the other hand, that's not as
horrible as it sounds: First of all, we knew (and at least I said a long
time ago) that at a certain point, the project will become big enough to
require official recognition of rank among the courtiers; you don't
avoid this fact by splitting the kingdom into smaller bits. And second,
we already _have_ unofficial maintainers for most of the modules in the
code, so all we have to do is make the role official.

Now before I hear too many outraged cries, let me explain that I'm not
proposing to change the way we make decisions in this community. Module
owners would be responsible for keeping the parts of the system they
oversee in sync with the whole. That would not give them extra voting
rights or similar, although I do expect that, by the nature of things,
the module owners would be people whose opinions carry weight by virtue
of their knowledge and experience. (The avant-garde of the working
peoples, first among equals -- very apt for the Subversion project,
don't you think? :-)

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org