You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Denis Magda <dm...@gridgain.com> on 2016/03/03 12:54:54 UTC
Switching back to review-then-commit process
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
Re: Switching back to review-then-commit process
Posted by Do...@ODDO,
od...@gmail.com.
+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
>
>
>
Re: Switching back to review-then-commit process
Posted by Anton Vinogradov <av...@gridgain.com>.
+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 <ds...@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" <dm...@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
> > >
> > >
> > >
> >
>
Re: Switching back to review-then-commit process
Posted by Roman Shtykh <rs...@yahoo.com.INVALID>.
+1 on Raul’s proposal.
-Roman
On Friday, March 4, 2016 2:47 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 <ds...@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" <dm...@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
> > >
> > >
> > >
> >
>
Re: Switching back to review-then-commit process
Posted by Raul Kripalani <ra...@apache.org>.
On Thu, Mar 3, 2016 at 5:46 PM, Raul Kripalani <ra...@apache.org> 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>
Re: Switching back to review-then-commit process
Posted by Dmitriy Setrakyan <ds...@apache.org>.
+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 <ds...@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" <dm...@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
> > > >
> > > >
> > > >
> > >
> >
>
Re: Switching back to review-then-commit process
Posted by Raul Kripalani <ra...@apache.org>.
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 <ds...@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" <dm...@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
> > >
> > >
> > >
> >
>
Re: Switching back to review-then-commit process
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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" <dm...@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
> >
> >
> >
>
Re: Switching back to review-then-commit process
Posted by Raul Kripalani <ra...@apache.org>.
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" <dm...@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
>
>
>
Re: Switching back to review-then-commit process
Posted by Denis Magda <dm...@gridgain.com>.
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 <se...@gmail.com>:
>
>> +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 <co...@apache.org>:
>>
>>> 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
>>>>
>>>>
>>
Re: Switching back to review-then-commit process
Posted by Alexey Kuznetsov <ak...@gridgain.com>.
I recommend to add Andrey Novikov as Visor maintainer.
On Mon, Mar 21, 2016 at 10:16 PM, Denis Magda <dm...@gridgain.com> 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 <sergi.vladykin@gmail.com
>> >
>> wrote:
>>
>> Looks good.
>>>
>>> Sergi
>>>
>>> 2016-03-21 16:37 GMT+03:00 Denis Magda <dm...@gridgain.com>:
>>>
>>> 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 <se...@gmail.com>:
>>>>>
>>>>> +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 <co...@apache.org>:
>>>>>>
>>>>>> 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
Re: Switching back to review-then-commit process
Posted by Denis Magda <dm...@gridgain.com>.
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 <se...@gmail.com>
> wrote:
>
>> Looks good.
>>
>> Sergi
>>
>> 2016-03-21 16:37 GMT+03:00 Denis Magda <dm...@gridgain.com>:
>>
>>> 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 <se...@gmail.com>:
>>>>
>>>> +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 <co...@apache.org>:
>>>>>
>>>>> 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
>>>>>>>
>>>>>>>
Re: Switching back to review-then-commit process
Posted by Pavel Tupitsyn <pt...@gridgain.com>.
Suspicious entries:
* C++ API Ivan Veselovsky
* Docker, Mesos, YARN integration Igor Sapego
On Mon, Mar 21, 2016 at 6:08 PM, Sergi Vladykin <se...@gmail.com>
wrote:
> Looks good.
>
> Sergi
>
> 2016-03-21 16:37 GMT+03:00 Denis Magda <dm...@gridgain.com>:
>
> > 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 <se...@gmail.com>:
> >>
> >> +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 <co...@apache.org>:
> >>>
> >>> 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
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >
>
Re: Switching back to review-then-commit process
Posted by Sergi Vladykin <se...@gmail.com>.
Looks good.
Sergi
2016-03-21 16:37 GMT+03:00 Denis Magda <dm...@gridgain.com>:
> 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 <se...@gmail.com>:
>>
>> +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 <co...@apache.org>:
>>>
>>> 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
>>>>
>>>>>
>>>>>
>>>>>
>>>
>
Re: Switching back to review-then-commit process
Posted by Denis Magda <dm...@gridgain.com>.
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 <se...@gmail.com>:
>
>> +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 <co...@apache.org>:
>>
>>> 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
>>>>
>>>>
>>
Re: Switching back to review-then-commit process
Posted by Sergi Vladykin <se...@gmail.com>.
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 <se...@gmail.com>:
> +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 <co...@apache.org>:
>
>> 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
>> >
>> >
>> >
>>
>
>
Re: Switching back to review-then-commit process
Posted by Sergi Vladykin <se...@gmail.com>.
+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 <co...@apache.org>:
> 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
> >
> >
> >
>
Re: Switching back to review-then-commit process
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Mon, Mar 21, 2016 at 8:45 AM, Branko Čibej <br...@apache.org> wrote:
> 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?
>
Most modules have 2 or 3 owners, responsible for reviewing changes. If
delayed reviews become an issue, which I doubt, we can always reassign or
add ownership.
> 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.
>
I think everyone is entitled to their own opinion. I personally had no
preference here and did not get involved in this community discussion.
However, it is clear that the community prefers this process, after giving
CTR an honest try, so let’s be respectful of the outcome.
>
> -- 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
> >>
> >>
> >>
>
>
Re: Switching back to review-then-commit process
Posted by Denis Magda <dm...@gridgain.com>.
Branko,
Personally, it's not clear to me why the decision on having RTC process
for committers for most critical modules shows our immaturity in a sense
of open source collaboration.
As Raul properly noted below, the committers were always using RTC
informally for most of the modules trying to reach each other asking to
check changes before they get merged. In my understanding it shows that
Ignite committers takes care more on the quality of the contributions
rather than on a number of patches that get merged in a day or in a
week. The only thing we did for now is that we put this type of
collaboration on a paper.
It's not feasible to create a super comprehensive test that will check
all the cases, it's not realistic to document every line of the internal
code. But it's always possible to check your contribution with a
committer who is more experienced in a specific functionality, get his
feedback and as a result grow your own expertise.
In my initial example I referred to Spark community that has a list of
maintainers as well. I think that this rule didn't lead to the project
stagnation but rather allowed to adopt Spark in tons of projects
worldwide by delivering releases with high quality. At this moment
Ignite community decided to go this way as well. We're free to change
our decision later if something doesn't work.
--
Denis
On 3/21/2016 6:45 PM, Branko Čibej wrote:
> 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
>>>
>>>
>>>
Re: Switching back to review-then-commit process
Posted by Branko Čibej <br...@apache.org>.
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
>>
>>
>>
Re: Switching back to review-then-commit process
Posted by Konstantin Boudnik <co...@apache.org>.
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
>
>
>
Re: Switching back to review-then-commit process
Posted by Alexey Kuznetsov <ak...@gridgain.com>.
+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 <dm...@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
>
>
>
--
Alexey Kuznetsov
GridGain Systems
www.gridgain.com