On Tue, 2008-01-29 at 23:24 -0800, Mark Slee wrote: > Hi Martin, > > *If I look at the initial committers list, I see a big portion to be > facebook developers. During incubation you should work on diversifying.* > > *Again, it seems like a huge contingent of facebook developers. You > really should work on diversification during incubation.* > > Points well taken. We actually have a much bigger list of developers who > have contributed significant patches to Thrift. The issue, as Upayavira > pointed out in his other email, is that Thrift is a project spanning > many programming languages but striving to make them all work together > seamlessly. The result is that we have many developers familiar with > particular language implementations, but not others. What we'd really > like to set up here is a system where there are different people with > committer priveleges to different parts of the project. It's really an > interesting community dynamic... over time (already in fact) *no one* > will really understand all the Thrift codebase. So what we'd like to > develop is a community where people may become experts in some languages > and have committer priveleges there but not universally. We erred on the > side of having the initial committer list be shorter at first, as we'd > have to figure out how exactly to structure a partitioned commiters > system in the Apache environment. > > 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. In another case, the Ruby implementation was initially done > at Facebook, but we have passed de facto ownership to Powerset after > some great patches from Kevin Clark which really improved the > implementation. We now also defer all Ruby code reviews, and if we had > the partioned committers system in place already I wouldn't even > recommend any Facebook developers (myself included) as initial > committers for the Ruby codebase. > > So... that's a lot of rambling, but it's sort of a unique committers > situation. Interested to hear if there are other projects that have had > this sort of setup. > > *Hmm, hosting at googlecode, or sourceforge would statisfy that as well. > So why does the project want to join Apache specifically?* > > One big reason is that we think this project could provide a lot of > utility for many other Apache projects. Having Thrift in Apache, closer > to other similar projects, should mean less obstacles to a clean > integration, more communication and input into the different use cases, > feature prioritization, and hopefully some development collaboration as > well. > > *What is the affiliation of Jake Luciani?* > > Jake runs a website http://www.junkdepot.com/ and has also independently > developed some open source applications built on top of Thrift, > available at: > http://code.google.com/p/thrudb/ > > This has also now been picked up by Ross McFarland, who's working on a > ThruDB-based document store: > http://diststore.com/ > > So... already we're seeing a cool open source mini-ecosystem develop > about Thrift. Facebook also plans to open source Scribe, a distributed > logging framework built on Thrift. If accepted into Apache, we'd likely > also include Scribe as a sub-project or contrib submission to Thrift. > We'd be interested to hear if that'd be appropriate or what the general > approach is to subprojects or non-core addons.
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. Regards, Upayavira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
