> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: Wednesday, February 04, 2009 2:41 AM
> To: Hyrum K. Wright
> Cc: dev_at_subversion.tigris.org
> Subject: Re: Spinning off the bindings
>
> I think we should integrate them *more*. Get more developers building
> and running the tests. Right now, they're a second class citizen, and
> I believe that's a problem.
For some integrations (e.g. Javahl and python) integrating them works great
as we have quite a lot of developers working on fixing issues on javahl.
(Javahl is never broken for more than a few hours)..
But who is looking after the ruby and perl bindings?
Are you volunteering to fix the tests that are broken for (I think) more
than a week now?
I'm not planning on fixing a language binding I will never use... A few
months before breaking the Windows build was taken just as heavy as this
broken ruby build right now.
I'm in favor for removing the bindings that aren't actively maintained from
our release process (and if a new maintainer would like that I would be glad
to help it moving to a separate project with its own release table).
With our ABI guarantees I don't think there is really a need for the
bindings releasing directly at the same time as the subversion release.
(But I'm certainly planning on releasing SharpSvn, AnkhSVN and Windows CLI
RC binaries when 1.6 branches.)
Bert
>
> Cheers,
> -g
>
>
> On Feb 3, 2009, at 11:59, "Hyrum K. Wright"
> <hyrum_wright_at_mail.utexas.edu
> > wrote:
>
> > This issue has come up a few times on IRC, but I don't know if we've
> > ever
> > discussed it here, so I'm opening this can of worms now: Should the
> > bindings be
> > spun off into their own project(s)?
> >
> > Having the bindings in our tree has its benefits. In the early days
> > of the
> > project, having a large binding surface encouraged the use of
> > Subversion as a
> > library, and led to increased adoption. By making the swig bindings
> > officially
> > supported, users know they can expect a certain quality when they
> > ship with our
> > releases. Also, the bindings tests (especially the ruby bindings)
> > provide
> > additional test coverage into our APIs, which helps uncover
> > additional bugs.
> >
> > However, in the last couple of years, it has seemed that shipping
> > the bindings
> > with the core libraries has been more of a hindrance than a help. I
> > seem to
> > recall more than one occasion where a release was held up because
> > the bindings
> > had problems, and a lack of knowledgeable maintainers[1] led to
> > delays. In
> > addition to catching bugs, the bindings tests also lead to spurious
> > errors which
> > can likewise delay development. The root cause seems to be a lack of
> > maintainers, due to Real Life, lack of interest or otherwise. And
> > shipping
> > unmaintained code is a Bad Thing: it's better to not ship code than
> > code that is
> > full of bit rot.
> >
> > There are already other projects which maintain bindings for
> > languages we do and
> > don't include, such as SharpSvn, SVNCPP, PySVN and others[2].
> > Should we follow
> > their lead and graduate our existing swig and JavaHL bindings into
> > separate
> > projects? If we did, here are a few questions:
> > * Where would we spin off the bindings to?
> > * How much work would be involved in doing this?
> > * Should/can it be done for 1.6?
> >
> > -Hyrum
> >
> > [1] No offense the the existing bindings maintainers, of course.
> > The developer
> > audience for the bindings is simply smaller than that of the core
> > libraries.
> > [2] http://subversion.tigris.org/links.html#bindings
> >
> > ------------------------------------------------------
> >
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageI
> d=1098250
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageI
> d=1099619
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1099772
Received on 2009-02-04 03:20:22 CET