shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Saputra <henry.sapu...@gmail.com>
Subject Re: RTC vs CTR was ( Review Request: Allow container implementations to more easily override and extend rpc registered service handlers. )
Date Wed, 25 Jul 2012 21:11:43 GMT
Oh yeah totally not copying from Hadoop bylaws =)

What I meant "similar" was to have a written bylaws as guidance for
committers and PMCs.

- Henry

On Wed, Jul 25, 2012 at 2:05 PM, Franklin, Matthew B.
<mfranklin@mitre.org> wrote:
>>-----Original Message-----
>>From: Henry Saputra [mailto:henry.saputra@gmail.com]
>>Sent: Wednesday, July 25, 2012 4:15 PM
>>To: dev@shindig.apache.org
>>Subject: Re: RTC vs CTR was ( Review Request: Allow container
>>implementations to more easily override and extend rpc registered service
>>handlers. )
>>
>>I am thinking about having Apache Shindig bylaws similar to what
>>Apache Hadoop has: http://hadoop.apache.org/bylaws.html which govern
>>how code commits should be conducted.
>
> +1, though I would use a different community's bylaws as an example [1].  Their definition
of Lazy consensus is a little off to me.   Ross Gardler wrote Rave's and it covers the concept
well[2].
>
> [1] http://hc.apache.org/bylaws.html  (note the section on #Code_Review)
> [2] http://rave.apache.org/docs/governance/lazyConsensus.html
>
>>
>>I'd like the simplicity of CTR but it needs to have good boundaries. I
>>really dont want us to come back to the old model where commits and
>>reviews just done with some people working in the same companies.
>>Reviews could be done early with some people but at the end should
>>targeted to dev list for final approval.
>>
>>- Henry
>>
>>On Wed, Jul 25, 2012 at 12:07 PM, Franklin, Matthew B.
>><mfranklin@mitre.org> wrote:
>>> Most communities I have seen eventually adopt a Commit Then Review
>>model over a Review Then Commit model.  Due to the complexity of Shindig, I
>>can understand wanting to make sure that bigger changes are reviewed;
>>however, for trivial changes such as this, would it be easier to just commit the
>>change?
>>>
>>> I am not a committer, so it is really up to you all.  IMO, it is a lot of overhead
>>to review everything :) .  If you do move to a CTR model, I would suggest
>>setting some boundaries so that you work into the model.  Maybe saying that
>>any change with x lines, etc.
>>>
>>>>-----Original Message-----
>>>>From: Dan Dumont [mailto:noreply@reviews.apache.org] On Behalf Of Dan
>>>>Dumont
>>>>Sent: Wednesday, July 25, 2012 2:28 PM
>>>>To: shindig; Dan Dumont
>>>>Subject: Review Request: Allow container implementations to more easily
>>>>override and extend rpc registered service handlers.
>>>>
>>>>
>>>>-----------------------------------------------------------
>>>>This is an automatically generated e-mail. To reply, visit:
>>>>https://reviews.apache.org/r/6141/
>>>>-----------------------------------------------------------
>>>>
>>>>Review request for shindig.
>>>>
>>>>
>>>>Description
>>>>-------
>>>>
>>>>Change rpc registration to return the old handler if there were any so that
>>>>container implementations may call into the previously registered handler
if
>>>>they wish to extend the existing behavior.
>>>>
>>>>
>>>>This addresses bug SHINDIG-1827.
>>>>    https://issues.apache.org/jira/browse/SHINDIG-1827
>>>>
>>>>
>>>>Diffs
>>>>-----
>>>>
>>>>
>>>>http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascri
>>pt/
>>>>features/container/container.js 1365569
>>>>
>>>>http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascri
>>pt/
>>>>features/rpc/rpc.js 1365569
>>>>
>>>>Diff: https://reviews.apache.org/r/6141/diff/
>>>>
>>>>
>>>>Testing
>>>>-------
>>>>
>>>>Tests pass.
>>>>
>>>>
>>>>Thanks,
>>>>
>>>>Dan Dumont
>>>

Mime
View raw message