Yes I can. Let me take a stab drafting one in the Shindig wiki so we could discuss and improve.
- Henry On Wed, Jul 25, 2012 at 5:49 PM, Ryan Baxter <rbaxte...@apache.org> wrote: > Henry would you want to take a stab at drafting up Shindig's? :) > > On Wed, Jul 25, 2012 at 5:11 PM, Henry Saputra <henry.sapu...@gmail.com>wrote: > >> 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. >> <mfrank...@mitre.org> wrote: >> >>-----Original Message----- >> >>From: Henry Saputra [mailto:henry.sapu...@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. >> >><mfrank...@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:nore...@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 >> >>> >>
