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>*
