Zitat von Joe Schaefer <joe_schae...@yahoo.com>:
----- 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.
Probably, there are not enough committers within Thrift project?
there are many many things that can be commited to trunk without in
deep review!
e.g.
- THRIFT-71
- THRIFT-164
- THRIFT-456
- THRIFT-505
- THRIFT-507
- THRIFT-582
- THRIFT-846
- THRIFT-849
- THRIFT-852
the problem is that many contributers, just as me, are ready to
contribute but are not able to commit.
Waiting a very long time until the stuff gets into the trunk version
forces peoples to no longer submit patches and enhancements to the
project. => That's definitely the wrong way!
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?
That's a great idea! Probably it makes sense to create a Wiki Page and
document the maturity of the different implementations and the
responsible committer or maintainer.
In that way implementations like C or JavaScript can be added to the
regular release but marked as new with additional info e.g. function
"foo" is not supported, binary protocol is missing etc.
=> in that way things like THRIFT-812 can be added to trunk, but
marked as untested
>
> 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.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
