Re: [Thrift] RE: [PROPOSAL] Thrift

[Upayavira <uv...@odoko.co.uk>]

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

Re: [Thrift] RE: [PROPOSAL] Thrift

[Jim Jagielski <ji...@jaguNET.com>]

On Jan 30, 2008, at 5:55 AM, 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.
>

++1... In fact, I would almost consider this a deal-breaker
for incubation.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [Thrift] RE: [PROPOSAL] Thrift

[Upayavira <uv...@odoko.co.uk>]

On Wed, 2008-01-30 at 11:50 -0500, Ben Maurer wrote:
> 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.

Exactly.

> 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.

The issue is a graduation issue. Thrift won't graduate with a
preponderance of Facebook committers - it needs to be a sufficient
balance of folks such that, even if Facebook pulled out of development,
Thrift would survive. Also, there needs to be sufficient non-Facebook
developers such that, should (heaven forbid) Facebook try to subvert the
project, there are sufficient developers to prevent this.

Of course, this concern applies to all companies, and is not specific to
Facebook.

Regards, Upayavira



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [Thrift] RE: [PROPOSAL] Thrift

[Ben Maurer <bm...@andrew.cmu.edu>]

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