Switching back to review-then-commit process

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Switching back to review-then-commit process

Denis Magda
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 



Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Alexey Kuznetsov-2
+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
Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Dood@ODDO
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 
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Raul Kripalani
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
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

dsetrakyan
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
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Anton Vinogradov
+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
> > >
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Raul Kripalani
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
> > >
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

dsetrakyan
+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
> > > >
> > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Raul Kripalani
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>
Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Roman Shtykh
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
> > >
> > >
> > >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Konstantin Boudnik-2
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
>
>
>

signature.asc (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Sergi
+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
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Sergi
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
>> >
>> >
>> >
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Denis Magda
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
>>>>
>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Denis Magda
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
>>>>
>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Sergi
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
>>>>
>>>>>
>>>>>
>>>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Pavel Tupitsyn-3
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
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Denis Magda
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
>>>>>>>
>>>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Alexey Kuznetsov-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Switching back to review-then-commit process

Branko Čibej
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
>>
>>
>>

12