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.
>
> 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
> burden.
I understand it's a burden. The real question is do we have the
resources to take on that burden. I'm sitting here telling you I'm
willing to taken on the burden for the perl bindings. I'm willing to
help with the python bindings as much as I can.
Justin appears to be doing an excellent job of maintaining the javahl
bindings (but I can't say for sure because I don't use them).
You're arguing that they should be moved off into a separate project.
This doesn't really diminish the burden of maintaining them. At best it
means that we don't have to keep them up with trunk. But if trunk is
either having portions merged to maintenance branches or being released
as a new major or minor release. We'll still have to do it eventually.
In my mind it's much easier to do little tweaks here and there then it
is to sit down with a new version and start trying to figure out what I
have to fix.
And to be honest, I'm a chronic procrastinator. Doing the work after
the release means I'm procrastinating whlie people need the bindings.
Doing the work as we goes gives me plenty of time to procrastinate. :)
> * 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.
Actually, I think it's easier to keep them up to date in realtime than
it is to go back later and to try and figure out what changes happened
and what we need to change in the bindings. A test suite helps doing it
after the fact. But no test suite we write is going to catch all the
changes you make that have potential impacts on the bindings.
For example if you add a new function call to the API. My test suite
isn't going to detect that and test it. I'll have to notice it and
write the test suite and potentially thunks or other support things to
handle that.
In the end, I still have to track trunk. No maintenance burden is
removed. All splitting it off really does is hides the bindings from
your view.
> * 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).
This seems really silly to me. You're -1 on someone else doing work?
Why? Nobody is expecting you, kfogel, to fix the bindings. And if they
break and nobody is interested in fixing them maybe they shouldn't be
core.
I'm not suggesting they become core tomorrow. That's silly. They're
clearly *NOT* ready for that classification. However, I do see that as
a worthy goal to work for.
I see things playing out like so:
a) We get the bindings caught up with the C API.
b) We enter maintenance mode and simply do work to keep up with the C
API.
c) If after several releases we can prove that we're willing an able to
maintain them and keep them up to core quality. Then we can talk about
applying core status to them.
Any talk about making them core now is premature. We don't have the
history to make the decision. We don't know how people are using them
really yet. There are just a lot of factors that aren't clear. These
same factors also make it difficult to say that they should never be
core.
> * 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,
> because...
I highly disagree with this characterization.
0.37.0 is the closest we've really come to bindings interfering with
your release. In the end you were held up by a little bit to vote for
some changes related to the bindings. ISTR that accounted for a whole
*HOUR* delay. *gasp*
At this point in recent history Josasder's internet connection has been a
bigger interference with releases than the bindings. Delaying
1.0.0-beta1 by 6 hours.
Frankly, the reason 0.37.0 was such a big hassle was we were in most
peoples view calling that a 1.0.0 release canidate. To me that means no
changes. So I was trying to get some changes in that I viewed as
*CRITICAL* for the bindings. The SWIG 1.3.2[01] fixes are just one
example.
SWIG 1.3.2[01] made changes to their API in a manner that made it
incompatable with older versions. I had two choices as to how to deal
with this:
a) Force everyone to upgrade to 1.3.20 or newer.
b) Make some build system changes and let everyone using 1.3.19 continue
to use it but let things work for 1.3.20 or newer.
Since 1.3.19 was the more common release, b seemed like a better option.
But I also was thinking about 1.0.0 having to exist as a viable release
for a long time. So I wanted to support the newer API. Especially,
since Mandrake cooker (which will become Mandrake 10.0 soon) was
shipping with SWIG 1.3.20 at the time.
So if there's anything to blame it's me for not realizing the issue with
1.3.20 by not tracking it more closely and working to fix the issue
sooner (believe me I'm not going to repeat that mistake again). clako
for running a 1.3.20 that wasn't a release and so it was missing the API
changes so 1.3.20 seemed to work fine for him. And everyone else for
being really wishy washy about what our future release cycle was going
to be like. If I'd known I had another month to get stuff in for 1.0.0
I wouldn't have made such an issue of bindings things in 0.37.0
But really Karl. Releases are always going to be difficult. The
bindings are fairly young and just getting used. We're going to find
bugs. And in the future I'm confident some other thing will be the
generator of release headaches.
> * ... as useful as the binding are, they are _not_ essential in the
> same way as Subversion itself.
This seems silly. By this logic we should select *ONE* network protocol
and call it core. Push the other one out of our tree. Because really
only one of them is essential. They both do the same job.
DAV is essential to me. But to be honest, I don't really care about
svnserve. But I'm not about to seriously suggest that we go ripping it
out.
But really I think you're understimating the essentialness of the
bindings. viewcvs and mailer.py two highly useful apps (and some would
say essential) depend upon the bindings.
You complain about seeing the commit emails about the bindings. But
hell you wouldn't have commit emails to read if the bindings weren't
there.
> * 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.)
Well I don't think decoupling is a good idea anymore. Maybe some
interim releases. But if we're going to do releases ever 6 weeks I'm
not sure that's even missing.
> 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 it will make the bindings less up to date. And be less
convienent for end users.
> 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?
Yeah but if most installations end up using viewcvs, mailer.py or
something else like it pretty much everyone will be needing the
bindings. So why should we be asking them to download a separate
tarball for that?
> 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.
I'm unconvinced that there is any price. For someone who's asking for
concrete examples. You're not giving any either. Give me concrete
examples of how the bindings are interfering with releases a *lot*
(emphasis yours)? What is the price users are paying exactly?
The few concrete examples you have given can be dealt with easily:
* Noise in the status file: Great make a bindings status file.
* Noise on the commit list: Fine make a separate list for bindings
commits. If a commit happens on both bindings and anything else send to
both lists. People on both lists can either keep both emails or filter
one of them.
* Noise in the commit logs: Write a script that hides the bindings only
commits from your view when you're writing the changes file.
None of these are particularly hard tasks. Though many of them end up
using the bindings to do them the easiest way. :)
Basically in my view, you just don't want to hear about the bindings. I
don't see a lot of agreement with you about the problems of having them
in our tree, I see some agreement, but nobody else explaining why they
agree. So I'm unclear if they agree with the problems you see or if
they have other reason. There's no clear consensus about making them
core or not. But that's an entirely separate issue that doesn't need to
be said today.
> 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.
I think you just don't understand the issues more than it being an us vs
them.
--
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 Tue Feb 24 21:22:04 2004