Ben Reser <ben@reser.org> writes:
> > * 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.
No, that's not what I meant. Of course I'm not -1 on someone else
doing work! :-)
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.
> 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*
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".
> But really Karl. Releases are always going to be difficult.
Nah, that's FUD :-). Most releases are not difficult, nor should they
be.
I'll post a separate mail about the central question here.
-K
---------------------------------------------------------------------
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:49:56 2004