+1 on Raul’s proposal, specifically ignite-core should always follow RTC process.
On Thu, Mar 3, 2016 at 9:46 AM, Raul Kripalani <ra...@apache.org> wrote: > 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 > > > > > > > > > > > > > > > > > >
