On Sun, Feb 22, 2004 at 05:53:03PM -0600, kfogel@collab.net wrote:
> Some people have posted to say that they want the bindings to be
> considered part of "core" subversion.
Yup. Put me in that camp.
>...
> * It's too hard to keep the bindings up to date in realtime -- I
I don't think we have a lack of volunteers to keep them up to date. The
problem has been a lack of awareness that issues are present. If a
regression tests popped up with an error in the bindings, then I think
you'd find more than enough people wanting to jump in and fix them.
>...
> * There is no consensus among the developers for treating bindings
> breakage as seriously as core breakage.
Simply because we've never posed the question. Personally, I find they are
just as much part of our API contract as the C APIs are. Thus, they are
just important. Consider the number of GUIs that are using the bindings
rather than the C APIs.
Hmm. In fact, turn that around. Name one GUI other than the cmdline which
uses the C APIs.
I'm with Greg Hudson here: there are a lot of *consumers* of those APIs,
which means that (for a universal cost/benefit gain) there is a need for
us to (sometimes) take a bit of pain to produce a greater good. But even
then, I think we're only talking about temporary pain. Since they *are*
just a reflection of the C API, then they will stabilize around that.
> 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).
IMO, there should be a bindings regression suite. And I'd suggest that
people run it automagically and post results to svn-breakage. But is it
mandatory for all devs to keep it working? Nope. Much like in httpd, it is
entirely possible that I might end up breaking the Windows server; I do my
best, but it can happen, and a Windows guy will come along and fix it.
[ in fact, I did this quite recently in APR -- totally hosed EBCDIC
systems... how the hell was I supposed to know :-) ]
And so the bindings regressions might not be part of *your* set of tests,
but I think that many others who are comfy with the bindings would run
them, too.
> * The bindings interfere a *lot* with releases -- I've been
For this latest release, sure. But I think you're talking about an
exceptional situation. The root cause of the interference was twofold:
people unaware that problems had to be fixed (the "awareness problem" I
mentioned above), and people wanting to get the bindings API into just as
solid of a shape as the C API. For this latter point, this is because
people see those bindings in the same light: just as important to get
right for this 1.0 release.
I think it is also important to consider that the bindings are goig to
stabilize around the API we established with the 1.0 release.
>...
> * ... as useful as the binding are, they are _not_ essential in the
> same way as Subversion itself.
I'd argue against that. A long time ago, we stated that tools such as
ViewCVS were just as important to the adoption of SVN, as SVN itself. And
that tool depends upon the bindings.
While we have commit-mail.pl, but there has also been a good amount of
activity around mailer.py. And that uses the bindings. I'd consider it
pretty critical infrastructure for SVN.
SVN without those two tools (let alone all the other scripts and GUIs that
are out there) would be useful, but I would (personally) consider them
*essential* to any SVN deployment.
> * 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.)
I think they're all reflections of the same API, so they are *very*
tightly coupled. I don't think you can separate them into distinct
releases.
> 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 think the only underlying issue is solving awareness. And moving the
bindings would completely eliminate any chance of fixing that.
> 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?
Yes, it is. And we're trading those N users' extra effort for a short term
problem that we're looking at right now.
> 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.
Eh? I've never felt any impact of problems in javahl. If there is a
regression suite for it, then I might. And I might even go and tweak some
Java code to make them compile again (or depending on the tests: to
actually work! :-).
>...
So that was rather long-ish. The shorter form might be "what Greg Hudson
said" :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 23 11:50:49 2004