On Tue, Feb 24, 2004 at 01:46:15PM -0600, kfogel@collab.net wrote:
> No, that's not what I meant. Of course I'm not -1 on someone else
> doing work! :-)
Good.
> What I meant is:
>
> Right now, the *entire* C code base is the responsibility of every
> full committer, in the sense that if you make a change anywhere, and
> some regression test fails that didn't fail before your change, then
> the change can't go in.
>
> I'm merely saying we shouldn't add that requirement for the bindings
> regression tests. If core code commits have to pass not only the core
> regression tests, but also the bindings tests, we'll add a significant
> burden on people whose expertise is in the C code but not the bindings
> (not to mention getting SWIG, configuring stuff correctly, etc).
>
> However, I understood "making the bindings as important as the core"
> to imply just that. If that's not what people mean, then great.
>
> I understand that you're not proposing to make them "core" in this
> sense right now, I'm just describing what "core" means to me.
Okay, I think we're talking about two different things. First of all I
want to explain that I don't expect, nor do I in anway think it is
possible, for every C API developer to fix bindings to match the changes
they make. That's just not realistic.
However, I do want the following things for the bindings:
a) A good test suite that people can run against them to know when we
have breakage. Especially, non bindings developers so that they can
alert the bindings developers as to the breakage.
b) API documentation of the bindings.
c) Compatability guarantees.
d) An effort to make sure that the bindings are complete implemetations,
in that they expose all the functionality of the C APIs. With the
exception of API's like the svn_io stuff that is exposed for portability
and the language provides a better alternative in the context of using
that language.
Here's my vision of how things would work in a world where bindings are
treated as core changes:
API changes can happen in two ways:
a) A discussion that eventually results in a patch that is discussed.
b) A change that is made somewhat unilaterally. Perhaps, it is a new
and evolving API.
In the case of case a bindings developers would participate in the
discussion of the change. If a patch is proposed then binding
developers can propose a patch to the bindings that deals with the
change. If such a patch is available when the C API change is ready to
commit then the bindings change should be committed *WITH* the C API
change.
If this is case a and a patch is not made available or is case b then
the patch will go in despite breaking or not exposing functionality to
the bindings. A note to the effect that this breaks the bindings or
that the bindings need to be worked on as a result should be noted in
the commit log. That way when a bindings developer reads through the
commit he'll go "Ohh I should do this."
Developers that are actually interested in working on the bindings will
of course be able to do that along with the C API changes. If not
they'll work as they always do. But collaborating with the bindings
developers to help keep the bindings up to date.
The bindings should be easy to build and to run the test suite. So that
C API developers who are interested in checking if their changes break
something can do so without a lot of hassle.
It may also be useful for each binding to have someone who claims
responsibility for meeting these standards. If we can't find someone
who is willing to accept this burden then those bindings don't belong in
our tree.
In short I want to collaberate with you to make bindings meet the same
quality standards as the core does now. I have no intention of making
you maintain the bindings. Nor would I ever expect you to. I spent
some time getting up to speed and I don't see any way I could demand
that you do the same.
> You are way, way off about the amount of time I personally spent
> thinking & corresponding about bindings issues, for releases and
> otherwise.
>
> Please try to widen your view a bit :-). "Hassle" doesn't necessarily
> mean "measurable release delay". It can also mean "other things
> didn't get done because this one thing took unexpected time".
Well you were using the "users" are paying for this burden. I assumed
you meant by delaying release schedules.
Besides removing the bindings from the project how can we help make the
bindings take less of your time? If we're eating up your time I'd guess
it's about trying to build system changes approved and what not. Maybe
there's something that is far less drastic that can remove the burden
from you?
> > But really Karl. Releases are always going to be difficult.
>
> Nah, that's FUD :-). Most releases are not difficult, nor should they
> be.
Not really. If you're following a schedule on a collaberative project
there are always going to be last minute issues. Last minute whining
about this or that thing that isn't going to get in.
The less often a project releases the more pronounced the issues are.
As people work to try to get their pet issues resolved. Some of our
problems lately have simply been 1.0.0 stresses and the uncertainty of
our future release schedule.
There are very few projects where I've seen releases always go easily.
They are usually very simply projects, with limited user bases or that
release new versions quite often.
So I don't think this is FUD. Maybe always was a bit of an exageration
though. I'm not fond of calling what people are saying FUD. FUD
implies a certain degree of malice on the part of the other person. I
didn't have any malice, just a different perception.
--
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 23:15:54 2004