You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Chia-Liang Kao <cl...@clkao.org> on 2003/12/17 13:38:21 UTC
Merge policies regarding bindings
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?
Cheers,
CLK
On Wed, Dec 17, 2003 at 06:22:16AM -0500, John Peacock wrote:
> I'm very eager that the Perl interface changes be completed in time for
> 1.0; sounds like you are going to miss 0.35.0 by a little, so it is going
> to be harder to get +3 to apply to 1.0...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by Patrick Mayweg <ma...@qint.de>.
Hi Mike,
C. Michael Pilato wrote:
>Garrett Rooney <ro...@electricjellyfish.net> writes:
>
>
>
>>Chia-Liang Kao wrote:
>>
>>
>>>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.
>>>
>>>
>>That makes perfect sense to me.
>>
>>
>
>And to me.
>
I would love that.
>
>
>
>>We should probably also document somewhere that the language bindings
>>are not holding themselves to the same backwards compatability
>>constraints that the core Subversion libraries are, just so nobody gets
>>the wrong idea about how stable they are.
>>
That depends on the bindings. I try to keep the javahl binding backward
compatable if possible.
>>
>>
>
>+1.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by "C. Michael Pilato" <cm...@collab.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> Chia-Liang Kao wrote:
> > 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.
>
> That makes perfect sense to me.
And to me.
> We should probably also document somewhere that the language bindings
> are not holding themselves to the same backwards compatability
> constraints that the core Subversion libraries are, just so nobody gets
> the wrong idea about how stable they are.
+1.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Chia-Liang Kao wrote:
> 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.
That makes perfect sense to me.
We should probably also document somewhere that the language bindings
are not holding themselves to the same backwards compatability
constraints that the core Subversion libraries are, just so nobody gets
the wrong idea about how stable they are.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by Erik Huelsmann <e....@gmx.net>.
> I think our users should expect that applications written against *any*
> bindings (C, Perl, Python, Java) distributed in the 'official' 1.0 should
> work
> for all of 1.0. This is where I think we start to define when/how we bump
There is substantial work pending for at least the Perl bindings. Would you
suggest not shipping them, delaying 1.0 or just give our users what we have
but without warrenty?
> SVN
> versions as a whole. I'd really like to see a discussion on what changes
> are
> going to merit bumps. What does a schema change mean? Protocol change?
> Core
> API change? I'd like to have those defined and public soon-ish. --
> justin
bye,
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by kf...@collab.net.
Eric Gillespie <ep...@pretzelnet.org> writes:
> We don't need to hold up a release waiting on the bindings. The
> point is, the bindings that ship with 1.0 will NOT be 1.0
> quality. If that is the case, it would be best to ship with the
> latest and greatest.
>
> We should be *encouraging* the use of the bindings. Shipping
> with bindings that aren't the best we have is no way to do that.
> Furthermore, it's insulting to those who are working hard to make
> them better.
Well, obviously no insult is intended here... :-)
My point is that one can't say for sure that a change touches only
bindings and affects nothing else, without inspecting it. That's why
bindings changes need to go through the same inspection process as
other 1.0 changes. (For example, some bindings changes tweak the
build system -- if there's a mistake, they could affect aspects of the
build that have nothing to do with bindings.)
Shipping with the latest bindings is fine, just not by skimping on
review.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by Eric Gillespie <ep...@pretzelnet.org>.
kfogel@collab.net writes:
> We can't have a policy of holding up major releases until all
> bindings are ready. The set of bindings is ever-increasing,
> and yet has fewer developers paying attention to it than the
> core code, so blocking on bindings is a recipe for delay.
We don't need to hold up a release waiting on the bindings. The
point is, the bindings that ship with 1.0 will NOT be 1.0
quality. If that is the case, it would be best to ship with the
latest and greatest.
We should be *encouraging* the use of the bindings. Shipping
with bindings that aren't the best we have is no way to do that.
Furthermore, it's insulting to those who are working hard to make
them better.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by kf...@collab.net.
Ben Reser <be...@reser.org> writes:
> So in summary. I'm fine with 3 +1s for binding updates. I do think we
> should be a little more flexible on what we merge in for the ones that
> are incomplete. But by more flexible I don't think automatic approval
> is the answer either. I just think they shouldn't necessarily be held
> to the standards that we would hold the C API too regarding not making
> major changes. I don't see any way to get them up to snuff without
> making some major changes.
Let's see what the changes look like and then decide.
After all, they have to be made eventually, if not for 1.0, then for
trunk leading to the next major release. So the work won't be wasted.
We can't have a policy of holding up major releases until all bindings
are ready. The set of bindings is ever-increasing, and yet has fewer
developers paying attention to it than the core code, so blocking on
bindings is a recipe for delay.
Nevertheless, we can still make an effort not to ship with broken
bindings, if the changes look good. Let's not decide in the abstract,
let's decide based on the changes themselves.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by Ben Reser <be...@reser.org>.
On Fri, Dec 19, 2003 at 01:46:45AM -0800, Justin Erenkrantz wrote:
> Depending upon how frequently we go through the 1.0->1.1->1.2 cycle, how
> about for the perl (or any other 'unstable' binding) saying that it'll be
> compatible for that minor series alone? The python bindings, on the other
> hand, would be expected to work in any 1.x series (like the C bindings).
>
> Perhaps that's a compromise that could work? So, you'd only be stuck with
> the bindings until we hit 1.2 (assuming odd/even dev cycles which isn't
> even agreed to yet).
Well honestly as someone who's trying to write an app with these
Bindings I can say they just aren't usable (client side at least, clkao
is using the lower level stuff to write svk which is better off than the
client side stuff, in fact it was the first thing I got to work when I
started looking at this). If we don't merge any of these changes that
I'm doing into 1.0 then nobody in their right mind is going to try and
use them for Client scripting. In which case the compatability
guarantee just isn't going to buy them much.
If we do put some of the changes in that I'm making now I could
certainly live with a minor to minor version compatability. Though I
would expect that we'll get to a point where we can be comfortable
making the same gurantee on compatability as you feel for python.
--
Ben Reser <be...@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
Re: Merge policies regarding bindings
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, December 19, 2003 12:53 AM -0800 Ben Reser <be...@reser.org> wrote:
> So in summary. I'm fine with 3 +1s for binding updates. I do think we
> should be a little more flexible on what we merge in for the ones that
> are incomplete. But by more flexible I don't think automatic approval
> is the answer either. I just think they shouldn't necessarily be held
> to the standards that we would hold the C API too regarding not making
> major changes. I don't see any way to get them up to snuff without
> making some major changes.
Depending upon how frequently we go through the 1.0->1.1->1.2 cycle, how about
for the perl (or any other 'unstable' binding) saying that it'll be compatible
for that minor series alone? The python bindings, on the other hand, would be
expected to work in any 1.x series (like the C bindings).
Perhaps that's a compromise that could work? So, you'd only be stuck with the
bindings until we hit 1.2 (assuming odd/even dev cycles which isn't even
agreed to yet).
What do ya'll think? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by Ben Reser <be...@reser.org>.
On Fri, Dec 19, 2003 at 12:15:26AM -0800, Justin Erenkrantz wrote:
> Perhaps a bindings/experimental directory would make it more clear that
> this is a work in progress? I don't know what the right thing is.
That's problematic because you'd have to spend a lot of time breaking
the SWIG stuff up. Especially since you consider the python bindings
stable.
> I'm just indicating what should be in place for 1.0 not 0.35.0. Things can
> definitely be merged back into 1.0 from the trunk after 0.35.0 goes out.
> (My perspective, though, it should be like everything else: it needs 3 +1s,
> etc.)
Not arguing that point. I think at least with the perl bindings there's
a compelling case of merging a lot of stuff. Even if that means some
backporting from what I've got done (e.g. if the authentication API
changes don't make 1.0 then I'll have to change some stuff in the stuff
I'm going to put up shortly.)
I just don't want to be held to supporting what is in there for 0.35.0
as a stable interface in the future. The work I'm doing now would be
significantly more complex to stay compatable with the way things are
now. And frankly it wouldn't be very valueable because I can't imagine
anyone wanting to use the perl bindings for the client side stuff the
way they are now. I'm not sure where clkao is with the other stuff,
I'll let him speak for himself on that.
> There are enough projects using the python bindings that I'd consider those
> definitely stable. If my mailer.py dies on a hypothetical 1.0.5->1.0.6,
> I'm gonna have a heart attack. I shouldn't have to worry about the python
> bindings breaking after we go to 1.0 as I consider it 'core.' (I consider
> everything under /trunk core, but that's besides the point.)
That may be. I don't know much about the python bindings because I
haven't used them. Looking at the .i files, I'd guess there are some
holes in the client API that aren't implemented (prompt callbacks). But
I may be wrong and that stuff may work right already.
> So, we could work from the other direction as well: what bindings are
> considered stable and can't break 'older' 1.0 clients in a 'minor' release?
Unless someone says otherwise the only ones I've heard anyone suggest
would qualify for that would be the python and javahl ones. I may get
to a point in the next week where I could say otherwise for the client
side stuff on perl. But I haven't even started looking at the wc lib
wrappings.
> I'd say anything related to generic SWIG (i.e. the .i files) and the
> Python-specific stuff fits needs to have the compatibility rules enforced.
There isn't a whole lot of "generic" SWIG stuff. Pretty much anything
in the .i files is language specific. The likelyhood that anyone would
need to change the stuff that isn't seems pretty slim to me. But I know
there's stuff in the .i files that isn't complete for perl at least.
Plenty of FIXME's.
So in summary. I'm fine with 3 +1s for binding updates. I do think we
should be a little more flexible on what we merge in for the ones that
are incomplete. But by more flexible I don't think automatic approval
is the answer either. I just think they shouldn't necessarily be held
to the standards that we would hold the C API too regarding not making
major changes. I don't see any way to get them up to snuff without
making some major changes.
--
Ben Reser <be...@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
Re: Merge policies regarding bindings
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, December 18, 2003 11:59 PM -0800 Ben Reser <be...@reser.org>
wrote:
> If that's the case we can't do a 1.0 yet. The perl bindings as they
> exist now are simply not complete. Until clako and I get them to a
> point where pertty much everything is implemented there's no way we can
> say for sure that things won't have to change.
Perhaps a bindings/experimental directory would make it more clear that this
is a work in progress? I don't know what the right thing is.
> I'd like to have the client side stuff done before 1.0 and I'm working
> my butt off to try and get that done. If it will be accepted or not I
> can't say. But I can tell you already that what's in 0.35.0 won't be
> very useful to most people.
I'm just indicating what should be in place for 1.0 not 0.35.0. Things can
definitely be merged back into 1.0 from the trunk after 0.35.0 goes out. (My
perspective, though, it should be like everything else: it needs 3 +1s, etc.)
> I think the reasonable thing to do is specify which bindings are up to
> snuff enough to be considered stable. I think the javahl stuff sounds
> like it might be... maybe the python bindings. The rest should be made
> clear that they aren't stable yet.
There are enough projects using the python bindings that I'd consider those
definitely stable. If my mailer.py dies on a hypothetical 1.0.5->1.0.6, I'm
gonna have a heart attack. I shouldn't have to worry about the python
bindings breaking after we go to 1.0 as I consider it 'core.' (I consider
everything under /trunk core, but that's besides the point.)
So, we could work from the other direction as well: what bindings are
considered stable and can't break 'older' 1.0 clients in a 'minor' release?
I'd say anything related to generic SWIG (i.e. the .i files) and the
Python-specific stuff fits needs to have the compatibility rules enforced. --
justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by Ben Reser <be...@reser.org>.
On Thu, Dec 18, 2003 at 11:09:20PM -0800, Justin Erenkrantz wrote:
> As a user, I'd be mad if my Perl code bound against 1.0.5 doesn't work in
> 1.0.6 because we have separate rules for the bindings that allow breakage.
>
> I think our users should expect that applications written against *any*
> bindings (C, Perl, Python, Java) distributed in the 'official' 1.0 should
> work for all of 1.0. This is where I think we start to define when/how we
> bump SVN versions as a whole. I'd really like to see a discussion on what
> changes are going to merit bumps. What does a schema change mean?
> Protocol change? Core API change? I'd like to have those defined and
> public soon-ish. -- justin
If that's the case we can't do a 1.0 yet. The perl bindings as they
exist now are simply not complete. Until clako and I get them to a
point where pertty much everything is implemented there's no way we can
say for sure that things won't have to change.
I'd like to have the client side stuff done before 1.0 and I'm working
my butt off to try and get that done. If it will be accepted or not I
can't say. But I can tell you already that what's in 0.35.0 won't be
very useful to most people.
I think the reasonable thing to do is specify which bindings are up to
snuff enough to be considered stable. I think the javahl stuff sounds
like it might be... maybe the python bindings. The rest should be made
clear that they aren't stable yet.
--
Ben Reser <be...@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
Re: Merge policies regarding bindings
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, December 17, 2003 2:17 PM -0600 kfogel@collab.net wrote:
> I think the bindings commits should be treated the same way as any
> other commit, as far as the 1.0 release branch goes.
I agree 100%. I don't think we should have exceptions.
> 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.
As a user, I'd be mad if my Perl code bound against 1.0.5 doesn't work in
1.0.6 because we have separate rules for the bindings that allow breakage.
I think our users should expect that applications written against *any*
bindings (C, Perl, Python, Java) distributed in the 'official' 1.0 should work
for all of 1.0. This is where I think we start to define when/how we bump SVN
versions as a whole. I'd really like to see a discussion on what changes are
going to merit bumps. What does a schema change mean? Protocol change? Core
API change? I'd like to have those defined and public soon-ish. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by Patrick Mayweg <ma...@qint.de>.
Hi,
Chia-Liang Kao wrote:
>The point I have is:
>
>* The bindings changes should not bring extra burden to release manager or
> other project members.
>
>* Merging such changes make the maintainer easier to support the bindings
> as that makes bindings more more current upon release.
>
>So perhaps the bindings maintainer should just have one-round merging request
>at a certain point before release to minimize the effort of the release manager.
>
>
Thats a good idea.
>Cheers,
>CLK
>
>On Wed, Dec 17, 2003 at 02:17:39PM -0600, kfogel@collab.net wrote:
>
>
>>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? :-)
>>
>>
The only problem I see, are API changes in the core which are merged
into the branches without the matching patches for the bindings. That
will unneccesary break the bindings. These revisions should be
considered together. I am working realy busy to keep in sync with the
recent api-changes of Tobias and Mike.
<OffTopic>
I would be great if the core developers would put a notification line
when they change the svn_client_* interfaces into their log messages.
Tobias put one into his recent commits. It makes it much easier for me
to notice.
</OffTopic>
Given that I see the javahl bindings a thin layer over the svn_client_*
calls, I think that they are as complete as they can be ;-) .
>>I think the bindings commits should be treated the same way as any
>>other commit, as far as the 1.0 release branch goes.
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by kf...@collab.net.
Patrick Mayweg <ma...@qint.de> writes:
> does that mean if the core changes have been merged into the 1.0
> branch, that I just can merge my changes too?
>
> Or if the discussion about merging a change starts, I comment by
> saying, please look at my depending change to?
The latter.
The main thing is, those bindings changes need to be reviewed before
they go in, just like anything else. What I'm resisting is any plan
that involves automatic approval just because one change is a
necessary consequence of another (for example, a bindings change is a
necessary consequence of an API change). The consequential change is
still a change, and therefore still needs review before going into 1.0.
That's all.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by Patrick Mayweg <ma...@qint.de>.
Hi Karl,
kfogel@collab.net wrote:
>Chia-Liang Kao <cl...@ayer.elixus.org> writes:
>
>
>>The point I have is:
>>
>>* The bindings changes should not bring extra burden to release manager or
>> other project members.
>>
>>* Merging such changes make the maintainer easier to support the bindings
>> as that makes bindings more more current upon release.
>>
>>So perhaps the bindings maintainer should just have one-round
>>merging request at a certain point before release to minimize the
>>effort of the release manager.
>>
>>
>
>Let's see what the state of the bindings is after any core changes
>(especially API changes) have been merged into the 1.0 branch, then.
>
>
For the recent api changes by Tobias and Mike, I already know that they
will break the javahl bindings.
>I'm not trying to ship with broken bindings, don't worry :-). But I
>do want to avoid auto-approving bindings commits. Bindings changes
>still need review, and I don't think we should exempt them from the
>1.0 voting process.
>
>When the time comes, each binding commit can say something like
>
> "This brings the bindings up-to-date with rXXXX, which was merged
> into 1.0 in rYYYY."
>
>That way people will know that this bindings change is a necessary
>consequence of some already-approved API change.
>
>
does that mean if the core changes have been merged into the 1.0 branch,
that I just can merge my changes too?
Or if the discussion about merging a change starts, I comment by saying,
please look at my depending change to?
>-Karl
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by kf...@collab.net.
Chia-Liang Kao <cl...@ayer.elixus.org> writes:
> The point I have is:
>
> * The bindings changes should not bring extra burden to release manager or
> other project members.
>
> * Merging such changes make the maintainer easier to support the bindings
> as that makes bindings more more current upon release.
>
> So perhaps the bindings maintainer should just have one-round
> merging request at a certain point before release to minimize the
> effort of the release manager.
Let's see what the state of the bindings is after any core changes
(especially API changes) have been merged into the 1.0 branch, then.
I'm not trying to ship with broken bindings, don't worry :-). But I
do want to avoid auto-approving bindings commits. Bindings changes
still need review, and I don't think we should exempt them from the
1.0 voting process.
When the time comes, each binding commit can say something like
"This brings the bindings up-to-date with rXXXX, which was merged
into 1.0 in rYYYY."
That way people will know that this bindings change is a necessary
consequence of some already-approved API change.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by Chia-Liang Kao <cl...@ayer.elixus.org>.
The point I have is:
* The bindings changes should not bring extra burden to release manager or
other project members.
* Merging such changes make the maintainer easier to support the bindings
as that makes bindings more more current upon release.
So perhaps the bindings maintainer should just have one-round merging request
at a certain point before release to minimize the effort of the release manager.
Cheers,
CLK
On Wed, Dec 17, 2003 at 02:17:39PM -0600, kfogel@collab.net wrote:
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge policies regarding bindings
Posted by kf...@collab.net.
Chia-Liang Kao <cl...@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