You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Joe Schaefer <jo...@yahoo.com> on 2010/08/14 18:25:15 UTC
sharing knowledge means sharing control
THRIFT-819 to me is a pattern of dialog I'd like
to see improved. Too often I see issues filed
in Thrift's jira that get turned down by Facebook
folks without any input from non-Facebook committers.
That tends to institutionalize the idea Facebook
retains tight control over all architectural decisions
for this project.
One way to resolve this is for the Facebook employees
to continue to comment on these issues but to ask for
input from other committers before closing the issue.
Another approach is to recognize the pattern and return
to the dev list with some educational posts about the
goals of Thrift and its design. Those suggestions
are not mutually exclusive.
Re: sharing knowledge means sharing control
Posted by ro...@bufferoverflow.ch.
I closed that issue by my self and I agree with David and Mark's statements.
It's absolutely OK for me, otherwise I would not close that issue and
discuss my position in detail.
The good thing with that issue was:
- fast response on second request
- doubt on feasibility
- good alternative idea
The Bad things with that issue was:
- no real discussion within the community, only two comments (no interest?)
- an additional question via mailing list was required to start the discussion
Personally I really do not care on Thrift's origin. I would like to
use and enhance a mature piece of software driven by community under
the umbrella of Apache. Just as other projects I recommend an accept
for my employer!
- attractive license for commercial use => APACHE, BSD or Beerware;-)
- active community (spread across different companies or individuals)
- well tested and stable
- scalable and portable
- no local patches required
- available via standard distros like Debian
bye the way... I played around with hudson (continuous integration) =>
looks good!
I'm currently configuring hudson ci for Thrift at home, as soon as its
ready to use I tell you and we can set it up at apache infrastructure
if possible!
Regards
roger
Zitat von Joe Schaefer <jo...@yahoo.com>:
> ----- Original Message ----
>
>> From: David Reiss <dr...@facebook.com>
>> To: thrift-dev@incubator.apache.org
>> Sent: Sat, August 14, 2010 1:28:58 PM
>> Subject: Re: sharing knowledge means sharing control
>>
>> > Too often I see issues filed
>> > in Thrift's jira that get turned down by Facebook
>> > folks without any input from non-Facebook committers.
>>
>> > One way to resolve this is for the Facebook employees
>> > to continue to comment on these issues but to ask for
>> > input from other committers before closing the issue.
>>
>> Joe, these comments frustrate me because the paint a negative picture of
>> Mark and myself that is simply inaccurate. Mark an I both pointed out
>> specific problems with the approach the submitter was taking and offered
>> alternative approaches to bypass the problems. Then the submitter
>> voluntarily closed his own issue. In general, I try to avoid closing
>> issues as invalid and let the submitter do so (as in THRIFT-692) unless
>> it is something obvious like a missing build dependency.
>
> To be clear, I'm questioning the pattern of "who" makes these
> decisions, not the decisions themselves. The comments I made
> are meant to raise awareness of the perception problem of having
> architectural decisions all being made by the same 2 people.
> It was not meant to paint you and Mark in a negative light.
> Sorry if it came across that way.
>
>> I think it's implied that any committer (or contributor for that matter)
>> should feel free to comment on any issue.
>
> Sometimes it takes an invitation to get folks to cross that boundary.
>
>
>
>
>
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Re: sharing knowledge means sharing control
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: David Reiss <dr...@facebook.com>
> To: thrift-dev@incubator.apache.org
> Sent: Sat, August 14, 2010 1:28:58 PM
> Subject: Re: sharing knowledge means sharing control
>
> > Too often I see issues filed
> > in Thrift's jira that get turned down by Facebook
> > folks without any input from non-Facebook committers.
>
> > One way to resolve this is for the Facebook employees
> > to continue to comment on these issues but to ask for
> > input from other committers before closing the issue.
>
> Joe, these comments frustrate me because the paint a negative picture of
> Mark and myself that is simply inaccurate. Mark an I both pointed out
> specific problems with the approach the submitter was taking and offered
> alternative approaches to bypass the problems. Then the submitter
> voluntarily closed his own issue. In general, I try to avoid closing
> issues as invalid and let the submitter do so (as in THRIFT-692) unless
> it is something obvious like a missing build dependency.
To be clear, I'm questioning the pattern of "who" makes these
decisions, not the decisions themselves. The comments I made
are meant to raise awareness of the perception problem of having
architectural decisions all being made by the same 2 people.
It was not meant to paint you and Mark in a negative light.
Sorry if it came across that way.
> I think it's implied that any committer (or contributor for that matter)
> should feel free to comment on any issue.
Sometimes it takes an invitation to get folks to cross that boundary.
Re: sharing knowledge means sharing control
Posted by David Reiss <dr...@facebook.com>.
> Too often I see issues filed
> in Thrift's jira that get turned down by Facebook
> folks without any input from non-Facebook committers.
> One way to resolve this is for the Facebook employees
> to continue to comment on these issues but to ask for
> input from other committers before closing the issue.
Joe, these comments frustrate me because the paint a negative picture of
Mark and myself that is simply inaccurate. Mark an I both pointed out
specific problems with the approach the submitter was taking and offered
alternative approaches to bypass the problems. Then the submitter
voluntarily closed his own issue. In general, I try to avoid closing
issues as invalid and let the submitter do so (as in THRIFT-692) unless
it is something obvious like a missing build dependency.
I think it's implied that any committer (or contributor for that matter)
should feel free to comment on any issue.
--David
On 08/14/2010 09:25 AM, Joe Schaefer wrote:
> THRIFT-819 to me is a pattern of dialog I'd like
> to see improved. Too often I see issues filed
> in Thrift's jira that get turned down by Facebook
> folks without any input from non-Facebook committers.
> That tends to institutionalize the idea Facebook
> retains tight control over all architectural decisions
> for this project.
>
> One way to resolve this is for the Facebook employees
> to continue to comment on these issues but to ask for
> input from other committers before closing the issue.
> Another approach is to recognize the pattern and return
> to the dev list with some educational posts about the
> goals of Thrift and its design. Those suggestions
> are not mutually exclusive.
>
>
>
Re: sharing knowledge means sharing control
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Joe Schaefer <jo...@yahoo.com>
> To: thrift-dev@incubator.apache.org
> Sent: Sat, August 14, 2010 9:54:53 PM
> Subject: Re: sharing knowledge means sharing control
>
> ----- Original Message ----
>
> > From: Todd Lipcon <to...@cloudera.com>
> > To: thrift-dev@incubator.apache.org
> > Sent: Sat, August 14, 2010 9:45:24 PM
> > Subject: Re: sharing knowledge means sharing control
> >
> > On Sat, Aug 14, 2010 at 12:25 PM, Joe Schaefer
><jo...@yahoo.com>wrote:
> >
> > > THRIFT-819 to me is a pattern of dialog I'd like
> > > to see improved. Too often I see issues filed
> > > in Thrift's jira that get turned down by Facebook
> > > folks without any input from non-Facebook committers.
> > > That tends to institutionalize the idea Facebook
> > > retains tight control over all architectural decisions
> > > for this project.
> > >
> > > One way to resolve this is for the Facebook employees
> > > to continue to comment on these issues but to ask for
> > > input from other committers before closing the issue.
> > > Another approach is to recognize the pattern and return
> > > to the dev list with some educational posts about the
> > > goals of Thrift and its design. Those suggestions
> > > are not mutually exclusive.
> > >
> > >
> > Isn't "lazy consensus" a core Apache principle?
> > I looked at the JIRA, saw that David had already commented,
> > and I agreed with his response. Piling on
> > just to say "I agree with David" seemed like a waste of time, no?
>
> Not quite. First off I'm talking about a pattern,
> not a single issue. And second off, that issue was
> opened a month ago, which was ample time for ANY
> interested committer to weigh in prior to David's
> response from yesterday. What's happenened here
> is that there are "territories" within the code that
> people accept (limited) responsibility for, and there
> needs to be more of a "swarm" effort to break down
> those walls. This isn't something Facebook folks
> can assist with other than to encourage others to
> step up and show some initiative.
Lemme give you an illustration of how an Apache-style community
would've handled THRIFT-819. First off, someone would've noticed
that a patch had been uploaded and that patch would've been examined
within a day or so. Then someone would've commented on the patch:
"Thanks for the patch, we're looking it over now. If you are interested
in a real-time discussion please join us on our IRC channel..."
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.
It should be the Facebook people deploying lazy concensus
whenever design decisions are made, not the other way round.
The other way round is just an expression of apathy or groupthink,
not informed decision-making.
Re: sharing knowledge means sharing control
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Todd Lipcon <to...@cloudera.com>
> To: thrift-dev@incubator.apache.org
> Sent: Sat, August 14, 2010 9:45:24 PM
> Subject: Re: sharing knowledge means sharing control
>
> On Sat, Aug 14, 2010 at 12:25 PM, Joe Schaefer <jo...@yahoo.com>wrote:
>
> > THRIFT-819 to me is a pattern of dialog I'd like
> > to see improved. Too often I see issues filed
> > in Thrift's jira that get turned down by Facebook
> > folks without any input from non-Facebook committers.
> > That tends to institutionalize the idea Facebook
> > retains tight control over all architectural decisions
> > for this project.
> >
> > One way to resolve this is for the Facebook employees
> > to continue to comment on these issues but to ask for
> > input from other committers before closing the issue.
> > Another approach is to recognize the pattern and return
> > to the dev list with some educational posts about the
> > goals of Thrift and its design. Those suggestions
> > are not mutually exclusive.
> >
> >
> Isn't "lazy consensus" a core Apache principle?
> I looked at the JIRA, saw that David had already commented,
> and I agreed with his response. Piling on
> just to say "I agree with David" seemed like a waste of time, no?
Not quite. First off I'm talking about a pattern,
not a single issue. And second off, that issue was
opened a month ago, which was ample time for ANY
interested committer to weigh in prior to David's
response from yesterday. What's happenened here
is that there are "territories" within the code that
people accept (limited) responsibility for, and there
needs to be more of a "swarm" effort to break down
those walls. This isn't something Facebook folks
can assist with other than to encourage others to
step up and show some initiative.
Re: sharing knowledge means sharing control
Posted by Todd Lipcon <to...@cloudera.com>.
On Sat, Aug 14, 2010 at 12:25 PM, Joe Schaefer <jo...@yahoo.com>wrote:
> THRIFT-819 to me is a pattern of dialog I'd like
> to see improved. Too often I see issues filed
> in Thrift's jira that get turned down by Facebook
> folks without any input from non-Facebook committers.
> That tends to institutionalize the idea Facebook
> retains tight control over all architectural decisions
> for this project.
>
> One way to resolve this is for the Facebook employees
> to continue to comment on these issues but to ask for
> input from other committers before closing the issue.
> Another approach is to recognize the pattern and return
> to the dev list with some educational posts about the
> goals of Thrift and its design. Those suggestions
> are not mutually exclusive.
>
>
Isn't "lazy consensus" a core Apache principle? I looked at the JIRA, saw
that David had already commented, and I agreed with his response. Piling on
just to say "I agree with David" seemed like a waste of time, no?
-Todd
--
Todd Lipcon
Software Engineer, Cloudera