----- Original Message ----
> From: "ro...@bufferoverflow.ch" <ro...@bufferoverflow.ch>
> To: thrift-dev@incubator.apache.org
> Sent: Sun, August 15, 2010 3:33:55 PM
> Subject: Re: sharing knowledge means sharing control
>
> 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!
+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.
