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. Just my .002c 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>*
