I would +1 RTC for a finite set of modules – core, complex or strategic modules – in agreement with the community, e.g. ignite-core, ignite-spark, ignite-hadoop, ignite-indexing, etc.
But it seems counterproductive to impose strict RTC for modules like ignite-kafka, ignite-flume, ignite-twitter, ignite-camel, etc. If someone changes a log in ignite-camel, I beg them not to wait for me (as the expert) to review it. If the change is larger, I expect them to ping me for a review *motu proprio*. Equally, it makes little sense for me to submit for review a change I am personally making to ignite-camel: no one is going to be interested in taking up this review and it'll probably end up in the tail of their workqueue – likely just delaying the commit. To sum up, my proposal: * RTC for core, complex and strategic modules (community defines a finite list). * RTC or CTR, at committer's discretion, for other modules – with a criteria of personal accountability and rationality. * CTR for contributors for all modules, for obvious reasons (no commit access ;-)). Cheers, *Raúl Kripalani* PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and Messaging Engineer http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani Blog: raul.io | twitter: @raulvk <https://twitter.com/raulvk> On Thu, Mar 3, 2016 at 5:09 PM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > I hate to be religious about anything, but do think that for most of the > functionality, RTC makes sense. > > On Thu, Mar 3, 2016 at 7:20 AM, Raul Kripalani <ra...@apache.org> wrote: > > > I thought we were already on RTC process. > > > > What do you mean with contributors following this process? > > > > Raúl. > > On 3 Mar 2016 11:54, "Denis Magda" <dma...@gridgain.com> wrote: > > > > > Igniters, > > > > > > I would propose to switch back to review-then-commit process. This > > process > > > has to be followed by both contributors and committers. > > > > > > There is a reason for this I have in mind. Ignite is a complex platform > > > with several big modules. Some of the people may be experts in module A > > > while others in module B etc. > > > If a committer, who is good in module A, makes changes in module B > > merging > > > the changes without a review this can break module's B internal > > > functionality that the committer didn't take into account. > > > > > > My proposal is to introduce a list of maintainers for every Ignite > module > > > like it's done in Spark [1] and a rule that will require a committer to > > get > > > an approval from a module maintainer before merging changes. > > > > > > Thoughts? > > > > > > -- > > > Denis > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers > > > > > > > > > > > >
