+1 On Thu, May 7, 2015 at 3:36 PM, Konstantin Boudnik <[email protected]> wrote:
> On Thu, May 07, 2015 at 02:54PM, William Markito wrote: > > Just to complement what I have said about component leaders: > > > > The important thing about this kind of assignment wouldn't be to have > only > > a single person to control them, but much more on to help the community > to > > work with the experts of each area/component and also to assign some > > responsibility to this people to review/look at the changes. > > > > We can always argue both ways, RTC or CTR have their own merits and > > benefits, but in the end of the day what we probably want is to make sure > > that the code base is stable and the core principles of the project > > (performance, for one) are always taken care of. > > Indeed. Although, the more important role of the mentors is to make sure > that > we are building a sound and vibrant community, which lives to "community > over > the code" (a somewhat counter-intuitive Apache) motto > > Cos > > > On Thu, May 7, 2015 at 2:19 PM, Konstantin Boudnik <[email protected]> > wrote: > > > > > RTC is great, but it tends to slow down the contribution process (for > > > existing > > > committers) and also might (in extreme cases) lead to a low-quality > > > reviews, > > > as it adds more work on developers. CTR on the other hand, will let the > > > changes to go in much faster but it requires a few things: > > > - mature committers who won't commit crap into the common code base > > > - well-oiled CI to ensure sufficient testing of new commits > > > - optionally, a longer time to gain the commit-bit > > > > > > Spark example is a bit extreme and I don't think it flies well with the > > > board@ nor it is really compatible with open-community model. > > > There's nothing wrong in having maintainers (for once we have it in > > > Bigtop), > > > but it is certainly wrong to promote these maintainers into the status > of a > > > component kings. > > > > > > Regards, > > > Cos > > > > > > On Thu, May 07, 2015 at 07:13AM, 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? > > > > > > > > > > > > Anthony > > > > > > > > [1] https://cwiki.apache.org/confluence/display/SPARK/Committers > > > > > > > > > > > > > > > > > On May 7, 2015, at 3:38 AM, Justin Erenkrantz < > [email protected]> > > > 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]> 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] > > > > >> > > > > > > > > > > > > > > > -- > > > > 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>* > -- 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>*
