Re: Re: [PROPOSAL] Thrift
On 2/1/08, Mark Slee <[EMAIL PROTECTED]> wrote: > > However, dropping parts of the code feels counterproductive to me, as I > think it might put up a perceived barrier to collaboration with the > Thrift project. As long as you remember that you can't release or graduate without properly audited code with a paper trail to the original author of the code. We wouldn't want developers to feel like their changes to Thrift won't be accepted without an up front investment of time building reputation > in the Thrift community. You need a paper trail, and you need people to maintain said code. Dropping code into a project is not the same as "creating a community", which is what Apache is about. Dropping code is something one can do very well at google code, or sourceforge. When you accept a code drop without getting the developer to maintain it, does it really help your community? Are the current active developers going to maintain a code base in a language that is not familiar to them? Also note that in order for the ASF to provide legal protection to the contributors, the code needs to be sound. I think reverting and reapplying these changes creates another risk. > Developers would have incentive to keep some language-specific changes > to themselves and not share them, simply because it would be more > efficient, not because they are philosophically opposed to open source > or sharing their changes at all. I don't understand what you are trying to say here. How does including the code a priori make it any different? When they want to contribute changes, they still need to go through proper channels: provide an ICLA, code grant or patch through JIRA/bugzilla with the proper annotation. > And to be quite frank, it feels very counterproductive to me to remove > code from the project with full a priori intention of putting it back > in. Are you sure you will get the appropriate ICLA's from all the authors that have contributed to the whole code base? We'd rather focus on keeping development open and moving forwards. > Removing people's code from the project could send an insulting and > negative message. You will not be able to graduate or release if not all code is accounted for. That is just the way it works. Either get the appropriate documentation (ICLA, code grant) from the contributors, strip the offending code or rewrite the offending code (ensuring the proper licensing). I am not sure how not including a code base without a proper licensing history would be considered insulting though. Martijn
Re: [Thrift] Re: Re: [PROPOSAL] Thrift
On Fri, 2008-02-01 at 17:21 -0800, David Reiss wrote: > Thanks for the explanations. Maybe it is too early for me to start > evangelizing, but let me know if either of these factors makes a difference. > > 1/ I don't think we would be putting any load on the Apache infrastructure > team. As Matthieu said, it would take about five minutes for one of us to > set > up the server. > > 2/ It would be almost as easy to mirror the master branch of the repository > into Subversion, so there is no reason the latest and greatest Thrift code > could not be available with the rest of the Apache products. As to evangelising, I'd say, come along, enter the world of the ASF, join its infrastructure list, help out, get to know us, come to ApacheCons and meet us (if you can). Evangelising will be much easier then! As to using git, I would personally have no problem with a developer (or a group of developers) chosing to use git on top of SVN (assuming it does not put undue load on our SVN servers, like some tools do). I would probably feel uncomfortable with a situation where all devs were _required_ to use git in order to participate in the project, as that would effectively make it a core part of the project. So (a) so long as all code resides in SVN and (b) no-one is required to use git, nor prejudiced against for not using it, I would not have any problems. Regards, Upayavira > Matthieu Riou wrote: > > On Feb 1, 2008 4:48 PM, Upayavira <[EMAIL PROTECTED]> wrote: > > > > > > > > On Fri, 2008-02-01 at 16:20 -0800, David Reiss wrote: > > > > J Aaron Farr wrote: > > > > > git could be an issue. > > > > > > > > Can you explain what the issue is with Git? We have at least seven > > > > contributors (three at Facebook, four external) using git-svn right > > now, > > > and I > > > > know that at least a few of us would really like to use native Git as > > > the main > > > > repository for Thrift. Paul Querna mentioned on the Thrift list that > > > Apache > > > > likes things to happen "in the open", but he said that others could > > > explain it > > > > better. > > > > > > I think the main issue is one of uniformity, not a technology. I'm quite > > > happy to believe that git has some significant advantages. > > > > > > However, the ASF has currently standardised on Subversion. It is where > > > _all_ of the ASF's code lies. If one ASF project chooses an alternative > > > source control, we no longer have all the code in one place. > > > > > > We already have this 'diversified' situation with wikis and with bug > > > tracking. We have two wikis (moin and confluence) and three bug trackers > > > (Jira/bugzilla/Scarab - although Scarab may have been shut down > > > already), and it certainly makes life harder in terms of maintenance. > > > > > > So, as an ASF infrastructure person, my first response to git would be > > > 'no', much like an accountant's answer would be 'no' when you ask them > > > for money. > > > > > > I think you should assume that you won't have git as a part of what you > > > get at Apache. You are welcome to enter the Apache world, and evangelise > > > as to why git would be good for the whole ASF, and it is certainly not > > > impossible that it could be adopted. However, if a project made > > > something like the installation and use of git a core part of their > > > proposal, you can be sure it wouldn't be accepted. > > > > > > > +1 > > > > Said differently, I would love to use Bazaar at the ASF. Some others would > > like Mercurial. You'd like Git. I bet we could even find a couple of people > > who'd like to get back to CVS. > > > > Also it would take me 5mn to setup a Bazaar repository on my machine and > > share it with friends. In the context of the foundation (where the current > > svn revision is 617723) it would probably take weeks to get something that > > would fly, plus years of maintenance behind. > > > > Cheers, > > Matthieu > > > > > > > > > > I hope that makes it a little clearer. It isn't the easiest thing to > > > explain. > > > > > > > Regards, Upayavira > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > ___ > Thrift mailing list > [EMAIL PROTECTED] > http://lists.pub.facebook.com/mailman/listinfo/thrift - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [Thrift] Re: Re: [PROPOSAL] Thrift
Thanks for the explanations. Maybe it is too early for me to start evangelizing, but let me know if either of these factors makes a difference. 1/ I don't think we would be putting any load on the Apache infrastructure team. As Matthieu said, it would take about five minutes for one of us to set up the server. 2/ It would be almost as easy to mirror the master branch of the repository into Subversion, so there is no reason the latest and greatest Thrift code could not be available with the rest of the Apache products. Thanks for your consideration! --David Matthieu Riou wrote: On Feb 1, 2008 4:48 PM, Upayavira <[EMAIL PROTECTED]> wrote: > > On Fri, 2008-02-01 at 16:20 -0800, David Reiss wrote: > > J Aaron Farr wrote: > > > git could be an issue. > > > > Can you explain what the issue is with Git? We have at least seven > > contributors (three at Facebook, four external) using git-svn right now, > and I > > know that at least a few of us would really like to use native Git as > the main > > repository for Thrift. Paul Querna mentioned on the Thrift list that > Apache > > likes things to happen "in the open", but he said that others could > explain it > > better. > > I think the main issue is one of uniformity, not a technology. I'm quite > happy to believe that git has some significant advantages. > > However, the ASF has currently standardised on Subversion. It is where > _all_ of the ASF's code lies. If one ASF project chooses an alternative > source control, we no longer have all the code in one place. > > We already have this 'diversified' situation with wikis and with bug > tracking. We have two wikis (moin and confluence) and three bug trackers > (Jira/bugzilla/Scarab - although Scarab may have been shut down > already), and it certainly makes life harder in terms of maintenance. > > So, as an ASF infrastructure person, my first response to git would be > 'no', much like an accountant's answer would be 'no' when you ask them > for money. > > I think you should assume that you won't have git as a part of what you > get at Apache. You are welcome to enter the Apache world, and evangelise > as to why git would be good for the whole ASF, and it is certainly not > impossible that it could be adopted. However, if a project made > something like the installation and use of git a core part of their > proposal, you can be sure it wouldn't be accepted. > +1 Said differently, I would love to use Bazaar at the ASF. Some others would like Mercurial. You'd like Git. I bet we could even find a couple of people who'd like to get back to CVS. Also it would take me 5mn to setup a Bazaar repository on my machine and share it with friends. In the context of the foundation (where the current svn revision is 617723) it would probably take weeks to get something that would fly, plus years of maintenance behind. Cheers, Matthieu > > I hope that makes it a little clearer. It isn't the easiest thing to > explain. > Regards, Upayavira > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Thrift] Re: Re: [PROPOSAL] Thrift
On Feb 1, 2008 4:48 PM, Upayavira <[EMAIL PROTECTED]> wrote: > > On Fri, 2008-02-01 at 16:20 -0800, David Reiss wrote: > > J Aaron Farr wrote: > > > git could be an issue. > > > > Can you explain what the issue is with Git? We have at least seven > > contributors (three at Facebook, four external) using git-svn right now, > and I > > know that at least a few of us would really like to use native Git as > the main > > repository for Thrift. Paul Querna mentioned on the Thrift list that > Apache > > likes things to happen "in the open", but he said that others could > explain it > > better. > > I think the main issue is one of uniformity, not a technology. I'm quite > happy to believe that git has some significant advantages. > > However, the ASF has currently standardised on Subversion. It is where > _all_ of the ASF's code lies. If one ASF project chooses an alternative > source control, we no longer have all the code in one place. > > We already have this 'diversified' situation with wikis and with bug > tracking. We have two wikis (moin and confluence) and three bug trackers > (Jira/bugzilla/Scarab - although Scarab may have been shut down > already), and it certainly makes life harder in terms of maintenance. > > So, as an ASF infrastructure person, my first response to git would be > 'no', much like an accountant's answer would be 'no' when you ask them > for money. > > I think you should assume that you won't have git as a part of what you > get at Apache. You are welcome to enter the Apache world, and evangelise > as to why git would be good for the whole ASF, and it is certainly not > impossible that it could be adopted. However, if a project made > something like the installation and use of git a core part of their > proposal, you can be sure it wouldn't be accepted. > +1 Said differently, I would love to use Bazaar at the ASF. Some others would like Mercurial. You'd like Git. I bet we could even find a couple of people who'd like to get back to CVS. Also it would take me 5mn to setup a Bazaar repository on my machine and share it with friends. In the context of the foundation (where the current svn revision is 617723) it would probably take weeks to get something that would fly, plus years of maintenance behind. Cheers, Matthieu > > I hope that makes it a little clearer. It isn't the easiest thing to > explain. > Regards, Upayavira > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [Thrift] Re: Re: [PROPOSAL] Thrift
On Fri, 2008-02-01 at 16:20 -0800, David Reiss wrote: > J Aaron Farr wrote: > > git could be an issue. > > Can you explain what the issue is with Git? We have at least seven > contributors (three at Facebook, four external) using git-svn right now, and > I > know that at least a few of us would really like to use native Git as the > main > repository for Thrift. Paul Querna mentioned on the Thrift list that Apache > likes things to happen "in the open", but he said that others could explain > it > better. I think the main issue is one of uniformity, not a technology. I'm quite happy to believe that git has some significant advantages. However, the ASF has currently standardised on Subversion. It is where _all_ of the ASF's code lies. If one ASF project chooses an alternative source control, we no longer have all the code in one place. We already have this 'diversified' situation with wikis and with bug tracking. We have two wikis (moin and confluence) and three bug trackers (Jira/bugzilla/Scarab - although Scarab may have been shut down already), and it certainly makes life harder in terms of maintenance. So, as an ASF infrastructure person, my first response to git would be 'no', much like an accountant's answer would be 'no' when you ask them for money. I think you should assume that you won't have git as a part of what you get at Apache. You are welcome to enter the Apache world, and evangelise as to why git would be good for the whole ASF, and it is certainly not impossible that it could be adopted. However, if a project made something like the installation and use of git a core part of their proposal, you can be sure it wouldn't be accepted. I hope that makes it a little clearer. It isn't the easiest thing to explain. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [PROPOSAL] Thrift
J Aaron Farr wrote: git could be an issue. Can you explain what the issue is with Git? We have at least seven contributors (three at Facebook, four external) using git-svn right now, and I know that at least a few of us would really like to use native Git as the main repository for Thrift. Paul Querna mentioned on the Thrift list that Apache likes things to happen "in the open", but he said that others could explain it better. If the concern is that key developers would maintain their own repositories and exchange patches in private emails, I can assure you that this is not what we have in mind. Perhaps it would help if I explained the sort of repository I am picturing. (I am locally testing some hooks to implement this, so hopefully we can launch it in a trial mode as soon as I can get a machine.) There would be once central repository that would track the trunk. In addition, every committer would be able to post their own branches to the repository. The preferred workflow would be for a committer to post a patch to a branch in the repo, then send out an email to the list like "hey guys, my patch for project space-age is on branch priv/dreiss/space-age. Do you think this is ready to be merged into master?" Then anyone could go to gitweb to look at the patch, pull the patch into their repo and hack on it, or download a tarball and test it out. I think this is much less error prone than having to manually apply a patch sent over an email. I think it even has the potential to be more open than Subversion. If we encourage developers to continuously push their experimental work to the repository in branches, everyone could "follow along" and contribute. I think this is a much better situation than the current case with Subversion where local changes that aren't ready to be merged into the main repository yet stay on developers' private machines. I also have a set of scripts to allow non-committers to submit changes directly to the repository, tag the submissions, and email a list of committers. There are two benefits of this. The first is that it is a far less error prone way for patches to be submitted and applied. The second is that non-committers would submit patches for consideration in almost the exact same way as committers. This way, new committers wouldn't have to change their workflows at all, and we wouldn't have to worry about them making "newbie" mistakes, because they would just continue to work in the same way that led us to believe they would be responsible committers. Well, this email is getting a bit long, so I'll cut myself off here. Let me say in closing, though, that I don't want this issue to hold up the vote on Thrift. I think that everyone involved with the project thinks that Apache is the best place for it, and if the PMC says we have to use Subversion, we will. But please consider Git. Thank you. --David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [PROPOSAL] Thrift
On Feb 1, 2008 2:32 PM, Mark Slee <[EMAIL PROTECTED]> wrote: > Following up on what David sent out yesterday, I think we're all on > board with having a single committers pool based upon mutual trust and > respect. > > However, dropping parts of the code feels counterproductive to me, as I > think it might put up a perceived barrier to collaboration with the > Thrift project. Alternate language bindings were one of the main things > we were really hoping to see come from the open source community, and > we'd like to make sure this continues to be a really approachable thing. > We wouldn't want developers to feel like their changes to Thrift won't > be accepted without an up front investment of time building reputation > in the Thrift community. > > I think reverting and reapplying these changes creates another risk. > Developers would have incentive to keep some language-specific changes > to themselves and not share them, simply because it would be more > efficient, not because they are philosophically opposed to open source > or sharing their changes at all. > > And to be quite frank, it feels very counterproductive to me to remove > code from the project with full a priori intention of putting it back > in. We'd rather focus on keeping development open and moving forwards. > Removing people's code from the project could send an insulting and > negative message. > I tend to agree with your observation. There have been donations in the past that weren't completely clear in term of IP at the time the incubation started and that have been cleared later on. IP cleanup is actually one of the main purpose of the incubator. So I don't think this is a roadblock for incubation even though it definitely is one for an official Apache release and you'll need to clear up the remaining issues *before* being able to release. I would also advise the creation of a page somewhere listing the parts of the code that have unclear IPs as well as their respective status for the sake of transparency and to keep track of the evolution. If you already have a good idea of what these parts are, maybe this could even be included in the proposal? Cheers, Matthieu > Cheers, > Mark > > -Original Message- > From: Martijn Dashorst [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 30, 2008 10:39 AM > To: general@incubator.apache.org > Subject: Re: Re: [PROPOSAL] Thrift > > Perhaps in the interest of code audit (which needs to be done) and > community building, the code parts of the missing committers should be > removed from the code drop prior to incubation start, and be > re-introduced inside the incubating podling by providing patches through > bugzilla? > Martijn > > On 1/30/08, David Reiss <[EMAIL PROTECTED]> wrote: > > > > > If there are people who have already proven their *merit* on the > > > project that are not included on the initial list of committers then > > > > I think they should be. > > > > > > In reality, many parts of the Thrift code base are already > > > entirely > owned by non-Facebook entities. The Cocoa, C#, Perl, and > > > > Smalltalk > implementations for Thrift were all developed entirely > > > outside of > Facebook, and although Facebook still maintains the > > > trunk, we defer > review of all these patches to the developers > > > working on those > libraries. > > > > > > So are these people on the initial list of committers? > > > > Perl was contributed by Jake Luciani, who is a committer, but the > > developers of the Cocoa, C#, and Smalltalk bindings are not. These > > bindings were submitted as a set of a few patches (or in some cases, > > even a single large patch), and added to the tree without extensive > > review because, quite frankly, no committers were qualified to review > > them. Because, as far as we know, the original contributors are the > > only users of these bindings, we've just been blindly committing any > > changes they make, so it would make sense for them to have commit > > access to their parts of the project. However, they have not been > > active enough in the Thrift community to warrant the trust that comes > > with full commit access. > > > > I would say that the requirements for a language-binding contributor > > to become a committer would be some amount of activity on the mailing > > list and either a significant review of the binding by a qualified > > committer or a significant project using the binding. > > > > --David > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is > released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: Re: [PROPOSAL] Thrift
Following up on what David sent out yesterday, I think we're all on board with having a single committers pool based upon mutual trust and respect. However, dropping parts of the code feels counterproductive to me, as I think it might put up a perceived barrier to collaboration with the Thrift project. Alternate language bindings were one of the main things we were really hoping to see come from the open source community, and we'd like to make sure this continues to be a really approachable thing. We wouldn't want developers to feel like their changes to Thrift won't be accepted without an up front investment of time building reputation in the Thrift community. I think reverting and reapplying these changes creates another risk. Developers would have incentive to keep some language-specific changes to themselves and not share them, simply because it would be more efficient, not because they are philosophically opposed to open source or sharing their changes at all. And to be quite frank, it feels very counterproductive to me to remove code from the project with full a priori intention of putting it back in. We'd rather focus on keeping development open and moving forwards. Removing people's code from the project could send an insulting and negative message. Cheers, Mark -Original Message- From: Martijn Dashorst [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 30, 2008 10:39 AM To: general@incubator.apache.org Subject: Re: Re: [PROPOSAL] Thrift Perhaps in the interest of code audit (which needs to be done) and community building, the code parts of the missing committers should be removed from the code drop prior to incubation start, and be re-introduced inside the incubating podling by providing patches through bugzilla? Martijn On 1/30/08, David Reiss <[EMAIL PROTECTED]> wrote: > > > If there are people who have already proven their *merit* on the > > project that are not included on the initial list of committers then > > I think they should be. > > > > In reality, many parts of the Thrift code base are already > > entirely > owned by non-Facebook entities. The Cocoa, C#, Perl, and > > Smalltalk > implementations for Thrift were all developed entirely > > outside of > Facebook, and although Facebook still maintains the > > trunk, we defer > review of all these patches to the developers > > working on those > libraries. > > > > So are these people on the initial list of committers? > > Perl was contributed by Jake Luciani, who is a committer, but the > developers of the Cocoa, C#, and Smalltalk bindings are not. These > bindings were submitted as a set of a few patches (or in some cases, > even a single large patch), and added to the tree without extensive > review because, quite frankly, no committers were qualified to review > them. Because, as far as we know, the original contributors are the > only users of these bindings, we've just been blindly committing any > changes they make, so it would make sense for them to have commit > access to their parts of the project. However, they have not been > active enough in the Thrift community to warrant the trust that comes > with full commit access. > > I would say that the requirements for a language-binding contributor > to become a committer would be some amount of activity on the mailing > list and either a significant review of the binding by a qualified > committer or a significant project using the binding. > > --David > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [PROPOSAL] Thrift
Niclas is correct - this can create hardships, resentments, control issues in your community. If it's a simple as "we don't trust you Java folks on day one to properly indent Python code" I can sympathize with that concept. That's about the extent of what we were thinking, but there has been so much opposition to this idea that Mark and I have decided to withdraw it from the proposal (wiki update coming soon). I think Ben said it best: if someone can't be trusted to not start committing changes to modules they are unfamiliar with, they should not be a committer at all. If we somehow get to a place where we are constantly merging patches from someone that we don't trust enough to make them a committer, we can discuss the possibility with our mentors. --David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [PROPOSAL] Thrift
Perhaps in the interest of code audit (which needs to be done) and community building, the code parts of the missing committers should be removed from the code drop prior to incubation start, and be re-introduced inside the incubating podling by providing patches through bugzilla? Martijn On 1/30/08, David Reiss <[EMAIL PROTECTED]> wrote: > > > If there are people who have already proven their *merit* on the > > project that are not included on the initial list of committers then I > > think they should be. > > > > In reality, many parts of the Thrift code base are already entirely > > > owned by non-Facebook entities. The Cocoa, C#, Perl, and Smalltalk > > > implementations for Thrift were all developed entirely outside of > > > Facebook, and although Facebook still maintains the trunk, we defer > > > review of all these patches to the developers working on those > > > libraries. > > > > So are these people on the initial list of committers? > > Perl was contributed by Jake Luciani, who is a committer, but the > developers > of the Cocoa, C#, and Smalltalk bindings are not. These bindings were > submitted as a set of a few patches (or in some cases, even a single large > patch), and added to the tree without extensive review because, quite > frankly, > no committers were qualified to review them. Because, as far as we know, > the > original contributors are the only users of these bindings, we've just > been > blindly committing any changes they make, so it would make sense for them > to > have commit access to their parts of the project. However, they have not > been > active enough in the Thrift community to warrant the trust that comes with > full commit access. > > I would say that the requirements for a language-binding contributor to > become > a committer would be some amount of activity on the mailing list and > either a > significant review of the binding by a qualified committer or a > significant > project using the binding. > > --David > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
Re: Re: [PROPOSAL] Thrift
If there are people who have already proven their *merit* on the project that are not included on the initial list of committers then I think they should be. > In reality, many parts of the Thrift code base are already entirely > owned by non-Facebook entities. The Cocoa, C#, Perl, and Smalltalk > implementations for Thrift were all developed entirely outside of > Facebook, and although Facebook still maintains the trunk, we defer > review of all these patches to the developers working on those > libraries. So are these people on the initial list of committers? Perl was contributed by Jake Luciani, who is a committer, but the developers of the Cocoa, C#, and Smalltalk bindings are not. These bindings were submitted as a set of a few patches (or in some cases, even a single large patch), and added to the tree without extensive review because, quite frankly, no committers were qualified to review them. Because, as far as we know, the original contributors are the only users of these bindings, we've just been blindly committing any changes they make, so it would make sense for them to have commit access to their parts of the project. However, they have not been active enough in the Thrift community to warrant the trust that comes with full commit access. I would say that the requirements for a language-binding contributor to become a committer would be some amount of activity on the mailing list and either a significant review of the binding by a qualified committer or a significant project using the binding. --David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
