Chia-Liang Kao <clkao@clkao.org> writes:
> I was thinking about proposing that bindings changes are allowed to be merged
> for 1.0. Since that all the bindings are not as complete as it
> should be under the '1.0' brand, nor does the stablization issues
> that people concern most seem to cover the bindings. In the case i
> think we should probably let the maintainer of the bindings to
> decide what is to be merged since they carry the responsiblity to
> support them after the release.
>
> Thoughts?
And will rushing in a bunch of commits at the last minute make the
bindings as complete as they should be for a 1.0 release? :-)
I think the bindings commits should be treated the same way as any
other commit, as far as the 1.0 release branch goes.
General comment:
I'm a little disturbed at the explosion of inclusion proposals we've
been seeing. I suppose it should have been predictable that once we
got serious about branching for 1.0, there'd be a bunch of changes
that people would want to get into the release at the last minute.
We're going to need to exercise some restraint here, if we want to
actually release this thing in a finite amount of time. Tracking each
change request in a master list -- in the issue tracker, currently --
forces us to be honest about how much flux we're looking at. (For
example, is issue #1653 really *necessary* for 1.0? And if we apply
the change, how much conflict will it cause with other outstanding
candidate patches?)
So no, I'm not in favor of automatic approval for bindings changes.
And I hope to get us to be a little more conservative about the other
proposed changes as well.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 17 22:07:33 2003