incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@odoko.co.uk>
Subject Re: [Thrift] RE: [PROPOSAL] Thrift
Date Wed, 30 Jan 2008 10:55:35 GMT

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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message