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 |
+1 from me. I could be a maintainer for following modules: visor-console,
schema-import-utility, ignite-web-console, scalar. We could even copy-paste rules from Spark wiki to ours. On Thu, Mar 3, 2016 at 6:54 PM, Denis Magda <[hidden email]> 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 > > > -- Alexey Kuznetsov GridGain Systems www.gridgain.com |
In reply to this post by Denis Magda
+1 - sounds very reasonable and practical.
On 3/3/2016 5:54 AM, Denis Magda 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 > > > |
In reply to this post by Denis Magda
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" <[hidden email]> 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 > > > |
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 <[hidden email]> 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" <[hidden email]> 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 > > > > > > > |
+1 (but I hope it's still up to a committer to decide whether a change
should need a review or not.) On Thu, Mar 3, 2016 at 8:09 PM, Dmitriy Setrakyan <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 > > > > > > > > > > > > |
In reply to this post by dsetrakyan
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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 > > > > > > > > > > > > |
+1 on Raul’s proposal, specifically ignite-core should always follow RTC
process. On Thu, Mar 3, 2016 at 9:46 AM, Raul Kripalani <[hidden email]> 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 <[hidden email]> > 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 <[hidden email]> 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" <[hidden email]> 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 > > > > > > > > > > > > > > > > > > |
In reply to this post by Raul Kripalani
On Thu, Mar 3, 2016 at 5:46 PM, Raul Kripalani <[hidden email]> wrote:
> * CTR for contributors for all modules, for obvious reasons (no commit > access ;-)). > Obviously, I meant RTC! *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> |
In reply to this post by Raul Kripalani
+1 on Raul’s proposal.
-Roman On Friday, March 4, 2016 2:47 AM, Raul Kripalani <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 > > > > > > > > > > > > |
In reply to this post by Denis Magda
It saddens me to see this coming to it ;(
On Thu, Mar 03, 2016 at 02:54PM, Denis Magda 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 > > > |
+1 to the original proposal of Denis to introduce module maintainers and
RTC process +1 to the proposal of Raul to restrict number of core modules, which require maintainers review Sergi 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik <[hidden email]>: > It saddens me to see this coming to it ;( > > On Thu, Mar 03, 2016 at 02:54PM, Denis Magda 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 > > > > > > > |
If everyone is ok with the proposals, then we need to set this new approach
and properly document it. Also we need to select list of RTC modules and elect their maintainers. Sergi 2016-03-05 19:31 GMT+03:00 Sergi Vladykin <[hidden email]>: > +1 to the original proposal of Denis to introduce module maintainers and > RTC process > +1 to the proposal of Raul to restrict number of core modules, which > require maintainers review > > Sergi > > > 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik <[hidden email]>: > >> It saddens me to see this coming to it ;( >> >> On Thu, Mar 03, 2016 at 02:54PM, Denis Magda 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 >> > >> > >> > >> > > |
Sergi,
I'll prepare a draft of the list of modules with their maintainers in the nearest days. -- Denis On 3/10/2016 1:37 PM, Sergi Vladykin wrote: > If everyone is ok with the proposals, then we need to set this new approach > and properly document it. > > Also we need to select list of RTC modules and elect their maintainers. > > Sergi > > 2016-03-05 19:31 GMT+03:00 Sergi Vladykin <[hidden email]>: > >> +1 to the original proposal of Denis to introduce module maintainers and >> RTC process >> +1 to the proposal of Raul to restrict number of core modules, which >> require maintainers review >> >> Sergi >> >> >> 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik <[hidden email]>: >> >>> It saddens me to see this coming to it ;( >>> >>> On Thu, Mar 03, 2016 at 02:54PM, Denis Magda 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 >>>> >>>> >> |
In reply to this post by Sergi
Igniters,
I've prepared a draft of the maintainers list. https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers Please review it and/or adjust it whenever is needed. If you have any thoughts, concerns let's discuss them there. -- Denis On 3/10/2016 1:37 PM, Sergi Vladykin wrote: > If everyone is ok with the proposals, then we need to set this new approach > and properly document it. > > Also we need to select list of RTC modules and elect their maintainers. > > Sergi > > 2016-03-05 19:31 GMT+03:00 Sergi Vladykin <[hidden email]>: > >> +1 to the original proposal of Denis to introduce module maintainers and >> RTC process >> +1 to the proposal of Raul to restrict number of core modules, which >> require maintainers review >> >> Sergi >> >> >> 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik <[hidden email]>: >> >>> It saddens me to see this coming to it ;( >>> >>> On Thu, Mar 03, 2016 at 02:54PM, Denis Magda 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 >>>> >>>> >> |
Looks good.
Sergi 2016-03-21 16:37 GMT+03:00 Denis Magda <[hidden email]>: > Igniters, > > I've prepared a draft of the maintainers list. > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers > > Please review it and/or adjust it whenever is needed. > > If you have any thoughts, concerns let's discuss them there. > > -- > Denis > > On 3/10/2016 1:37 PM, Sergi Vladykin wrote: > >> If everyone is ok with the proposals, then we need to set this new >> approach >> and properly document it. >> >> Also we need to select list of RTC modules and elect their maintainers. >> >> Sergi >> >> 2016-03-05 19:31 GMT+03:00 Sergi Vladykin <[hidden email]>: >> >> +1 to the original proposal of Denis to introduce module maintainers and >>> RTC process >>> +1 to the proposal of Raul to restrict number of core modules, which >>> require maintainers review >>> >>> Sergi >>> >>> >>> 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik <[hidden email]>: >>> >>> It saddens me to see this coming to it ;( >>>> >>>> On Thu, Mar 03, 2016 at 02:54PM, Denis Magda 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 >>>> >>>>> >>>>> >>>>> >>> > |
Suspicious entries:
* C++ API Ivan Veselovsky * Docker, Mesos, YARN integration Igor Sapego On Mon, Mar 21, 2016 at 6:08 PM, Sergi Vladykin <[hidden email]> wrote: > Looks good. > > Sergi > > 2016-03-21 16:37 GMT+03:00 Denis Magda <[hidden email]>: > > > Igniters, > > > > I've prepared a draft of the maintainers list. > > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers > > > > Please review it and/or adjust it whenever is needed. > > > > If you have any thoughts, concerns let's discuss them there. > > > > -- > > Denis > > > > On 3/10/2016 1:37 PM, Sergi Vladykin wrote: > > > >> If everyone is ok with the proposals, then we need to set this new > >> approach > >> and properly document it. > >> > >> Also we need to select list of RTC modules and elect their maintainers. > >> > >> Sergi > >> > >> 2016-03-05 19:31 GMT+03:00 Sergi Vladykin <[hidden email]>: > >> > >> +1 to the original proposal of Denis to introduce module maintainers and > >>> RTC process > >>> +1 to the proposal of Raul to restrict number of core modules, which > >>> require maintainers review > >>> > >>> Sergi > >>> > >>> > >>> 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik <[hidden email]>: > >>> > >>> It saddens me to see this coming to it ;( > >>>> > >>>> On Thu, Mar 03, 2016 at 02:54PM, Denis Magda 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 > >>>> > >>>>> > >>>>> > >>>>> > >>> > > > |
Oops, a misprint. Fixed, thanks Pavel.
-- Denis On 3/21/2016 6:14 PM, Pavel Tupitsyn wrote: > Suspicious entries: > * C++ API Ivan Veselovsky > * Docker, Mesos, YARN integration Igor Sapego > > On Mon, Mar 21, 2016 at 6:08 PM, Sergi Vladykin <[hidden email]> > wrote: > >> Looks good. >> >> Sergi >> >> 2016-03-21 16:37 GMT+03:00 Denis Magda <[hidden email]>: >> >>> Igniters, >>> >>> I've prepared a draft of the maintainers list. >>> >>> >> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers >>> Please review it and/or adjust it whenever is needed. >>> >>> If you have any thoughts, concerns let's discuss them there. >>> >>> -- >>> Denis >>> >>> On 3/10/2016 1:37 PM, Sergi Vladykin wrote: >>> >>>> If everyone is ok with the proposals, then we need to set this new >>>> approach >>>> and properly document it. >>>> >>>> Also we need to select list of RTC modules and elect their maintainers. >>>> >>>> Sergi >>>> >>>> 2016-03-05 19:31 GMT+03:00 Sergi Vladykin <[hidden email]>: >>>> >>>> +1 to the original proposal of Denis to introduce module maintainers and >>>>> RTC process >>>>> +1 to the proposal of Raul to restrict number of core modules, which >>>>> require maintainers review >>>>> >>>>> Sergi >>>>> >>>>> >>>>> 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik <[hidden email]>: >>>>> >>>>> It saddens me to see this coming to it ;( >>>>>> On Thu, Mar 03, 2016 at 02:54PM, Denis Magda 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 >>>>>>> >>>>>>> |
I recommend to add Andrey Novikov as Visor maintainer.
On Mon, Mar 21, 2016 at 10:16 PM, Denis Magda <[hidden email]> wrote: > Oops, a misprint. Fixed, thanks Pavel. > > -- > Denis > > > On 3/21/2016 6:14 PM, Pavel Tupitsyn wrote: > >> Suspicious entries: >> * C++ API Ivan Veselovsky >> * Docker, Mesos, YARN integration Igor Sapego >> >> On Mon, Mar 21, 2016 at 6:08 PM, Sergi Vladykin <[hidden email] >> > >> wrote: >> >> Looks good. >>> >>> Sergi >>> >>> 2016-03-21 16:37 GMT+03:00 Denis Magda <[hidden email]>: >>> >>> Igniters, >>>> >>>> I've prepared a draft of the maintainers list. >>>> >>>> >>>> >>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers >>> >>>> Please review it and/or adjust it whenever is needed. >>>> >>>> If you have any thoughts, concerns let's discuss them there. >>>> >>>> -- >>>> Denis >>>> >>>> On 3/10/2016 1:37 PM, Sergi Vladykin wrote: >>>> >>>> If everyone is ok with the proposals, then we need to set this new >>>>> approach >>>>> and properly document it. >>>>> >>>>> Also we need to select list of RTC modules and elect their maintainers. >>>>> >>>>> Sergi >>>>> >>>>> 2016-03-05 19:31 GMT+03:00 Sergi Vladykin <[hidden email]>: >>>>> >>>>> +1 to the original proposal of Denis to introduce module maintainers >>>>> and >>>>> >>>>>> RTC process >>>>>> +1 to the proposal of Raul to restrict number of core modules, which >>>>>> require maintainers review >>>>>> >>>>>> Sergi >>>>>> >>>>>> >>>>>> 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik <[hidden email]>: >>>>>> >>>>>> It saddens me to see this coming to it ;( >>>>>> >>>>>>> On Thu, Mar 03, 2016 at 02:54PM, Denis Magda 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 >>> >>>> >>>>>>>> >>>>>>>> > -- Alexey Kuznetsov GridGain Systems www.gridgain.com |
In reply to this post by Konstantin Boudnik-2
On 05.03.2016 04:43, Konstantin Boudnik wrote:
> It saddens me to see this coming to it ;( Yeah. You guys are introducing red tape that's a barrier for new committers and a bureaucratic trap for everyone else. For example: what happens when a module owner takes off for a couple months? Which is likely, since this is, after all, a volunteer effort. Are you going to block any changes to that module until/unless she becomes active again, or just break your own rules for convenience? Maybe you're counting on many module owners being employed to do this stuff ... in which case you should all go back to the incubator because you've learned NOTHING about open source collaboration in all this time. Pah, what nonsense. -- Brane P.S.: Also please stop using "Ignite is complex" as an argument for locking down on progress. Give the other guy the courtesy of assuming he's not a total idiot. How about spending time on a comprehensive test suite and developer documentation instead? > On Thu, Mar 03, 2016 at 02:54PM, Denis Magda 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 >> >> >> |
Free forum by Nabble | Edit this page |