Re: [Thrift] RE: [PROPOSAL] Thrift
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Thrift] RE: [PROPOSAL] Thrift
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]
Re: [Thrift] RE: [PROPOSAL] Thrift
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]
Re: [Thrift] RE: [PROPOSAL] Thrift
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
