Good points jan. I think many OSS communities don’t go as far as Spark did in codifying component leadership. Do you find that reviewers tend to self-select around code areas they have expertise in?
Anthony > On May 7, 2015, at 10:50 AM, jan i <[email protected]> wrote: > > ý > > On Thursday, May 7, 2015, William Markito <[email protected] > <mailto:[email protected]>> wrote: > >> On Thu, May 7, 2015 at 10:04 AM, Pid <[email protected] <javascript:;>> >> wrote: >> >>> On 07/05/2015 15:13, Anthony Baker wrote: >>>> Agree that RTC is really important. In addition, we should consider >>> that some changes require specific knowledge and context (I’m thinking of >>> you AbstractRegionMap). Note that I’m not advocating for code ownership. >>> Spark [1] uses this approach: >>>> >>>> "For certain modules, changes to the architecture and public API should >>> also be reviewed by a maintainer for that module (which may or may not be >>> the same as the main reviewer) before being merged. The PMC has >> designated >>> the following maintainers…” >>>> >>>> Changes to public API’s or core internals would fall into this >>> category. Thoughts? >>> >>> Good points on context; there's a lot of code to understand. >>> >>> Is knowledge about specific components concentrated in specific people >>> (or groups of people) in the existing developer team? >>> >>> >> Things will get more clear when have the components under Jira. We should >> then have the leaders (experts) for such components and they will have to >> review such critical changes. > > > Having leaders for components that must review changes is very hard to > combine with an open community. It is ok and a good idea to have > specialists and take their advice seriously. > > In a community everybody should be equal and have the same rights. > > just my opinion. > rgds > jan i > > >> >> >> >>> >>> >>> >>>> Anthony >>>> >>>> [1] https://cwiki.apache.org/confluence/display/SPARK/Committers >>>> >>>> >>>> >>>>> On May 7, 2015, at 3:38 AM, Justin Erenkrantz <[email protected] >> <javascript:;>> >>> wrote: >>>>> >>>>> One question that we need to discuss is whether every merge is RTC >>>>> (Review-than-Commit) or CTR (Commit-than-Review). >>>>> >>>>> My take is that we should start with RTC and, if the review process >>> gets in >>>>> the way of innovation, then we go to CTR. But, until everyone learns >>> the >>>>> rules of the road, I think RTC is justified. Under RTC rules, all >>> commits >>>>> should be reviewed (+1) by three committers before being merged. (If >>> you >>>>> are a committer, then two others are needed.). Any committer can veto >>> (-1) >>>>> a patch - which should cause a discussion about resolving the veto. >>>>> >>>>> So, #1 - your suggestion sounds right with the need for three >>> committers to >>>>> approve before merge to develop. >>>>> >>>>> For #2, I think it should be a separate branch and require 3 signoffs >>> for >>>>> now. >>>>> >>>>> As the project matures, "obvious" commits can be CTR. >>>>> >>>>> My $.02. -- justin >>>>> On May 7, 2015 5:44 AM, "Pid" <[email protected] <javascript:;>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> Like it says, can we discuss how the review process will work? >>>>>> For these examples: >>>>>> >>>>>> >>>>>> 1. I would like to work on upgrading the Spring dependencies in gfsh. >>>>>> >>>>>> Proposed approach: file a JIRA, cut a feature branch, push it & then >>> what? >>>>>> >>>>>> >>>>>> 2. I would like to add an entry to .gitignore (.idea/) >>>>>> >>>>>> Does this require a JIRA, a feature branch and a review? >>>>>> >>>>>> >>>>>> >>>>>> p >>>>>> >>>>>> -- >>>>>> >>>>>> [key:62590808] >>>>>> >>>> >>> >>> >>> -- >>> >>> [key:62590808] >>> >> >> >> >> -- >> >> William Markito Oliveira >> Enterprise Architect >> *http://www.pivotal.io/ <http://www.pivotal.io/>* >> For prompt responses to questions on GemFire/GemFireXD, please write >> to *rtds-dev-ea >> at pivotal.io <http://pivotal.io>* >> > > > -- > Sent from My iPad, sorry for any misspellings.
