On Sun, Aug 15, 2010 at 12:58 PM, Joe Schaefer <[email protected]>wrote:
> ----- Original Message ---- > > After some group discussion had happened, or perhaps after someone > > researched the patch themselves and drew their own conclusion, > > someone would have made a decision (up or down or ask for mods) > > about the patch and provided that feedback on the issue. > > That process from submission to decision should take 2-3 days > > to a week for something like this. Other folks could then > > weigh in with supporting statements or conflicting ones, in > > which case the issue should be brought back here for debate. > > > The reality is that there are a limited number of people who are able to make thoughtful decisions/discussions about each part of the code. I've barely used the C++ library, and never used Thrift's support for C#, Haskell, Perl, Ruby, JavaScript, AS3, OCaml, Cocoa, or Smalltalk. So, I'm not going to comment on patches that pertain to those languages, and I think the same is true for most of the community members (committer or otherwise). We each use some subset of Thrift, and blindly applying patches to languages we don't know about is a bad idea. A long time ago I proposed keeping a document around that classified each language as "stable", "development", or "unstable" (or something to that effect). The idea is that we'd accept any patch "nearly blind" for an unstable language, provided it's been available on the JIRA for a couple days. For "development" we'd probably have some more strict requirements, but still not require full review before commit, and for "stable" we'd follow the current model. This would allow us to iterate quickly on the languages that aren't quite done yet, but not worry about breaking the most commonly used languages (C++, Java, Python, and Ruby I think?) One possible requirement would be that for a language to be "stable" we'd need to have an active committer who will agree to review patches. > > Nobody can force the devs here to adopt the "community > over code" mantra, but if there isn't a serious collective effort > at treating patch submitters with respect and encouragement > this project simply won't graduate. It's not what cassandra > is about (and is precisely why it's been a success at Apache), > and it shouldn't be what thrift is about either. > > Why the constant comparisons to Cassandra? Although it was originally developed at Facebook, the Facebook developers are not involved whatsoever in the Apache project and have not contributed any patches to it since it entered the incubator. Moreover, Cassandra is a lot easier to accept patches for, as it's a single-language project where most of the code is used by most of the people, where Thrift is 15-language project where most people use 20% of them. -Todd -- Todd Lipcon Software Engineer, Cloudera
