[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: javahl situation

From: Ben Reser <ben_at_reser.org>
Date: 2004-01-13 20:15:38 CET

On Tue, Jan 13, 2004 at 10:28:59AM -0600, kfogel@collab.net wrote:
> A bindings change can go in with a +1 from either a bindings
> maintainer for that area or a full committer, and at least one "+0" or
> "+1 (concept)" from any other committer.

So would r8270 be already approved under this system as both clako and
myself have +1'ed it? I think you're saying it would be. I'm just a
bit unclear on how you're defining "any other committer." Do you mean:
any other full committer or partial committer in that area? Or do you
mean just flat out any other committer full or partial? I guess in
either of those scenarios r8270 would be already approved. Either one
works for me.

> If people prefer, we can apply this system to just the javahl bindings
> for now, but I think it would be more comprehensible if applied to all
> the bindings. And after all, nothing is stopping someone from
> reviewing a change if they want to, no matter how many votes it
> already has.

I think it's better to have a consistent approval system for all the
bindings. There are times when all of the competent people aren't going
to have time to review things. Right now at least with the perl
bindings it takes the vast majority of those that are competent to
review them for anything to happen.

So +1 on doing this for all the bindings.

-- 
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 Jan 13 20:16:11 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.