ý On Thursday, May 7, 2015, William Markito <[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.
