On Wed, 30 Jan 2008, Upayavira wrote:
As you can see from other proposals, I think you'll find it work better
with a single committer pool. As others have said, I personally have
never seen a problem with this approach - people steer away from code
that they are unfamiliar with, or tend to ask permission before
wandering that way. So, so while separating committerships might sound
useful, I don't think it is really necessary.
"Control" of codebases works best in Apache when it is done through
human respect rather than access rights - in the end, the whole project
management committee (which is made up of all or some committers, plus
mentors during incubation) is responsible for the whole codebase.
+1 for this. Having "committer" access does not mean "unilateral
permission to check in new code". I think that Thrift is going to need a
code review model that is more strict than projects of a similar age --
Thrift is so essential for a number of people's production infratructure
that having many eyes look over patches is important.
People given commit access should be trusted to be reasonable with the
power they have been granted. If this level of trust isn't present, then
they shouldn't have ANY commit access.
In regards to too many Facebook developers -- I don't think this is a huge
issue at this point. What is most important is that the folks at Facebook
are open about contributions they make and that they treat non-Facebook
developers equally. I think that this is already happening, and that the
Facebook developers are committed to making this a ture community project.
- Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
