----- Original Message ----
> From: Todd Lipcon <t...@cloudera.com>
> To: thrift-dev@incubator.apache.org
> Sent: Sun, August 15, 2010 1:24:09 PM
> Subject: Re: sharing knowledge means sharing control
>
> On Sun, Aug 15, 2010 at 12:58 PM, Joe Schaefer <joe_schae...@yahoo.com>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.
I dunno about other people here, but my first experience with patch
submissions to Thrift was for the LICENSE document. I would think
that a patch of that nature is applicable by any committer, and as
a member of the Apache Infrastructure Team would hope that any suggestion
that you are applying it "blindly" is simply a misunderstanding.
The fact is that it sat there unaddressed in Jira for months, and it
wasn't until you showed up here that anyone expressed interest in
reviewing it and/or applying it, even tho I happen to know you'd
never be able to release thrift at Apache without it. That is part
of the reason you were made a committer on the project, but I was
disappointed by your unwillingness to document the release process
as you learned it from me. Instead Bryan had to rediscover it
for himself, which isn't my idea of how collaborative projects operate.
>
> 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.
Sounds like a great idea. Is anybody else interested?
> >
> > 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?
Because the problems faced by the Cassandra community prior to bringing
that codebase to Apache are the same sorts of issues "the community"
needs to address here. When patch reviews take over a year to happen
as they do here, that is a call to action. Either start bringing in
these patch submitters to do their own review as fellow committers,
or strengthen the resolve of the existing devs to not let patches
continue to fall thru the cracks. Doing a bit of both is better
than doing nothing at all.
