----- Original Message ----
From: "[email protected]" <[email protected]>
To: [email protected]
Sent: Sun, August 15, 2010 3:33:55 PM
Subject: Re: sharing knowledge means sharing control
Zitat von Joe Schaefer <[email protected]>:
> ----- Original Message ----
>
>> From: Todd Lipcon <[email protected]>
>> To: [email protected]
>> 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
<[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.
>
> 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!
+1!
>
>>
>> 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.
While I support the idea of documenting the relative maturity of
each language
binding within Thrift, I'm not so sure it's wise to declare who is
responsible
for each one of those. The group of committers needs to have collective
oversight
over the entire codebase, and even though each person may specialize
in one or
two languages that's not a breakdown that should (continue to) be emphasized.
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.
+1. The more exposure new code gets, the more quickly it will stabilize
as patches come in for it. Definitely take advantage of the fact that
Thrift is a good ways away from a 1.0 release.
