Re: Moving bindings into a separate project.

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.
>
> * 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.
>
>

That's easy to solve. Treat bindings that are not actively maintained as
obsolete, and throw them out. If people don't show enough interest to
keep them up-to-date, they die. This is how open source projects work.
The only thing that would happen if you move the bindings to a separate
project is that you'd suddnely be saddled with a ton of dead projects
that you can't do anything about, whereas the core team can decide to
kill a set of bindings that aren't toeing the line.

(Note -- I said not a word about how we define "actively maintained".
The definition can be as relaxed as "up-to-date by the beginning of the
beta cycle for the next release", or as strict as "always build and all
tests pass", which is more or less what we require for the libraries.)

> * 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).
>
>

I agree with this, as bindings are clearly dependent on the core, not
the other way around. However, instituting the office of "bindings
maintainer", as I suggested in another mail -- and actually defining
quality standards for bindings changes -- would at least get the
bindings under control, which at this moment they're not.

> * 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.
>

"Several releases in a row." Yeah right. When's the time you next expect
to have a 2-week release cycle?

> Enough is enough,
> because...
>
> * ... as useful as the binding are, they are _not_ essential in the
> same way as Subversion itself.
>
>

Here, I think, we're in violent disagreement.

> * 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.)
>
>

With which you gain not the slighest bit as far as bindings maintenance
is concerned.

>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.
>
>

First of all, moving bindings to a separate project adds project
management overhead. Yes, it does, even if we've not had much official
visible project management here.

Second, it _does_ remove core knowledge from bindings maintenance; I
don't think very many people have the time or energy to follow yet
another project and yet another mailing list. (I know I've been remiss
in keeping up with APR, and I'm a PMC member there!)

And last, there's no reason why the set of targets for bindings can't be
the set of released Subversions even if they stay part of the project,
*if this is the policy we adopt*. And there's the rub -- we haven't
_any_ real policy. Moving bindings into a separate project is only
papering over this problem, or fobbing it off on whichever poor devil
finds the thing in his lap.

By the way, up to now, the set of bindings targets realistically _has_
been the set of released Subversions; it's just that we've had so many
releases in the last several months (years) that we can hardly follow
them. Since this will change post-1.0, the bindings maintenance burden
becomes quite different.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org