date:20181029

Also from https://www.apache.org/foundation/how-it-works.html there is no
mention of the word "privileges", maybe "right" is a better term.

I feel there is some wisdom in choose not to emphasize the entitlements
being given in the role. After all, the PMC/committership is given by the
community, and the main job of PMC/committer is to use the power serve the
community well. And we should choose wisely as our actions have
consequences, and the community is watching

Tianqi

On Mon, Oct 29, 2018 at 10:03 PM Tianqi Chen  wrote:

> As far as I recall from what Jim said
>
> "The ASF strives for consensus, and votes and voting are used, primarily,
> to gauge that. It's not used to divide a community; it's used to UNITE it.
> Voting is used when collaboration and consensus building *FAILS*. It should
> be rare."
>
> In this context, we all agree that when a veto vote occurs everyone should
> respect it and not kick a dead horse.  On the other hand, the
> PMC/committers should be cautious when using this power, as the community
> should always encourage reach consensus via reasonable technical discussion
> first.
>
> As with all the ML models, every guideline can be interpreted in an
> adversarial fashion but I hope we can have a goodwill to build toward a
> positive sum collaboration.
>
> Tianqi
>
>
>
> On Mon, Oct 29, 2018 at 9:01 PM Naveen Swamy  wrote:
>
>> The committer/PMC privileges is derived from
>> https://www.apache.org/foundation/how-it-works.html.
>>
>> The term abuse is very subjective (in this case) - If an opinion or Vote
>> is
>> against something they prefer, it can be termed as Abuse. I would expect
>> those who differ with the vote to take that as feedback, if there are
>> corrections to be made in the understanding, they respectfully clarify
>> that
>> misunderstanding.
>>
>> I agree with Chris, we have seen in the past where discussions have gone
>> on
>> and on for a long time when there were disagreements until people gave up,
>> This leads to frustration and less participation by members - this is also
>> an ultimate productivity killer. You can see why some of the discuss
>> threads go quiet and die.
>>
>> I am all for discussion and reaching consensus but at some point one must
>> realize its just kicking a dead horse and turns into an endurance contest
>> rather than a discussion. We should be careful on the expectations we set
>> in regard to how we reach consensus.
>>
>>
>> On Mon, Oct 29, 2018 at 6:18 PM Chris Olivier 
>> wrote:
>>
>> > well, if something needs consensus to pass, then saying “you need to
>> keep
>> > discussing until consensus is reached” seems like it could be abused by
>> > someone who was just willing to not accept a verdict and continues to
>> push,
>> > right? And if someone were to walk away saying “I don’t want to discuss
>> > this any further”, which is fair in that situation, then they’re the
>> “bad
>> > guy”? While it sounds like a noble persuit, I just feel like this could
>> be
>> > abused.
>> >
>> > On Mon, Oct 29, 2018 at 5:53 PM Carin Meier 
>> wrote:
>> >
>> > > Chris,
>> > >
>> > > Is there are rewording that you would find more acceptable? Again, we
>> can
>> > > have more time to edit and revise the document. There is not a time
>> limit
>> > > on this. I might have been too hasty to start the vote thinking the
>> > > discussion was wrapped up.
>> > >
>> > > - Carin
>> > >
>> > > On Mon, Oct 29, 2018 at 8:50 PM Chris Olivier 
>> > > wrote:
>> > >
>> > > > or another example if something is downvoted, this also implies that
>> > > after
>> > > > a vote is over, it’s approprorate to continue pushing the subject
>> > trying
>> > > to
>> > > > just wear everyone down even though the outcome is clear. We’ve seen
>> > this
>> > > > before, actually.
>> > > >
>> > > > On Mon, Oct 29, 2018 at 5:41 PM Chris Olivier <
>> cjolivie...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > -1 “strive to meet consensus”? This seems to imply the consensus
>> is
>> > the
>> > > > > natural expected state. So in the case where someone submits that
>> we
>> > > > should
>> > > > > start a nuclear war, then our bylaws would state that we should
>> all
>> > try
>> > > > to
>> > > > > agree to start a nuclear war.
>> > > > >
>> > > > > On Mon, Oct 29, 2018 at 4:41 PM Tianqi Chen 
>> > wrote:
>> > > > >
>> > > > >> Hi Carin:
>> > > > >> Sorry for the last minute request, but given the way we write
>> > down
>> > > > the
>> > > > >> PMC, committer privileges, I feel we need to add an additional
>> line:
>> > > > >>
>> > > > >>- "PMC/committer should strive to be diplomatic and reach
>> > consensus
>> > > > >> with
>> > > > >> discussion when possible."
>> > > > >>
>> > > > >>Since I don't really want us to give an impression of abusing
>> > veto
>> > > > >> rights.
>> > > > >>
>> > > > >> Thanks!
>> > > > >> Tianqi
>> > > > >>
>> > > > >> On Mon, Oct 29, 2018 at 3:47 PM Carin Meier <
>> carinme...@gmail.com>
>> > > > wrote:
>> > > > >>
>> > > > >> > This vote is to

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

As far as I recall from what Jim said

"The ASF strives for consensus, and votes and voting are used, primarily,
to gauge that. It's not used to divide a community; it's used to UNITE it.
Voting is used when collaboration and consensus building *FAILS*. It should
be rare."

In this context, we all agree that when a veto vote occurs everyone should
respect it and not kick a dead horse.  On the other hand, the
PMC/committers should be cautious when using this power, as the community
should always encourage reach consensus via reasonable technical discussion
first.

As with all the ML models, every guideline can be interpreted in an
adversarial fashion but I hope we can have a goodwill to build toward a
positive sum collaboration.

Tianqi



On Mon, Oct 29, 2018 at 9:01 PM Naveen Swamy  wrote:

> The committer/PMC privileges is derived from
> https://www.apache.org/foundation/how-it-works.html.
>
> The term abuse is very subjective (in this case) - If an opinion or Vote is
> against something they prefer, it can be termed as Abuse. I would expect
> those who differ with the vote to take that as feedback, if there are
> corrections to be made in the understanding, they respectfully clarify that
> misunderstanding.
>
> I agree with Chris, we have seen in the past where discussions have gone on
> and on for a long time when there were disagreements until people gave up,
> This leads to frustration and less participation by members - this is also
> an ultimate productivity killer. You can see why some of the discuss
> threads go quiet and die.
>
> I am all for discussion and reaching consensus but at some point one must
> realize its just kicking a dead horse and turns into an endurance contest
> rather than a discussion. We should be careful on the expectations we set
> in regard to how we reach consensus.
>
>
> On Mon, Oct 29, 2018 at 6:18 PM Chris Olivier 
> wrote:
>
> > well, if something needs consensus to pass, then saying “you need to keep
> > discussing until consensus is reached” seems like it could be abused by
> > someone who was just willing to not accept a verdict and continues to
> push,
> > right? And if someone were to walk away saying “I don’t want to discuss
> > this any further”, which is fair in that situation, then they’re the “bad
> > guy”? While it sounds like a noble persuit, I just feel like this could
> be
> > abused.
> >
> > On Mon, Oct 29, 2018 at 5:53 PM Carin Meier 
> wrote:
> >
> > > Chris,
> > >
> > > Is there are rewording that you would find more acceptable? Again, we
> can
> > > have more time to edit and revise the document. There is not a time
> limit
> > > on this. I might have been too hasty to start the vote thinking the
> > > discussion was wrapped up.
> > >
> > > - Carin
> > >
> > > On Mon, Oct 29, 2018 at 8:50 PM Chris Olivier 
> > > wrote:
> > >
> > > > or another example if something is downvoted, this also implies that
> > > after
> > > > a vote is over, it’s approprorate to continue pushing the subject
> > trying
> > > to
> > > > just wear everyone down even though the outcome is clear. We’ve seen
> > this
> > > > before, actually.
> > > >
> > > > On Mon, Oct 29, 2018 at 5:41 PM Chris Olivier  >
> > > > wrote:
> > > >
> > > > > -1 “strive to meet consensus”? This seems to imply the consensus is
> > the
> > > > > natural expected state. So in the case where someone submits that
> we
> > > > should
> > > > > start a nuclear war, then our bylaws would state that we should all
> > try
> > > > to
> > > > > agree to start a nuclear war.
> > > > >
> > > > > On Mon, Oct 29, 2018 at 4:41 PM Tianqi Chen 
> > wrote:
> > > > >
> > > > >> Hi Carin:
> > > > >> Sorry for the last minute request, but given the way we write
> > down
> > > > the
> > > > >> PMC, committer privileges, I feel we need to add an additional
> line:
> > > > >>
> > > > >>- "PMC/committer should strive to be diplomatic and reach
> > consensus
> > > > >> with
> > > > >> discussion when possible."
> > > > >>
> > > > >>Since I don't really want us to give an impression of abusing
> > veto
> > > > >> rights.
> > > > >>
> > > > >> Thanks!
> > > > >> Tianqi
> > > > >>
> > > > >> On Mon, Oct 29, 2018 at 3:47 PM Carin Meier  >
> > > > wrote:
> > > > >>
> > > > >> > This vote is to adopt the document
> > > > >> >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > > > >> > to replace the current document
> > > > >> >
> > > >
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > > > >> >
> > > > >> > The dev discussion thread is here
> > > > >> >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
> > > > >> >
> > > > >> > The vote will be a procedural issue vote as defined
> > > > >> > https://www.apache.org/foundation/voting.html
> > > > >> >
> > > > >>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

2018-10-29 Thread Naveen Swamy

The committer/PMC privileges is derived from
https://www.apache.org/foundation/how-it-works.html.

The term abuse is very subjective (in this case) - If an opinion or Vote is
against something they prefer, it can be termed as Abuse. I would expect
those who differ with the vote to take that as feedback, if there are
corrections to be made in the understanding, they respectfully clarify that
misunderstanding.

I agree with Chris, we have seen in the past where discussions have gone on
and on for a long time when there were disagreements until people gave up,
This leads to frustration and less participation by members - this is also
an ultimate productivity killer. You can see why some of the discuss
threads go quiet and die.

I am all for discussion and reaching consensus but at some point one must
realize its just kicking a dead horse and turns into an endurance contest
rather than a discussion. We should be careful on the expectations we set
in regard to how we reach consensus.


On Mon, Oct 29, 2018 at 6:18 PM Chris Olivier  wrote:

> well, if something needs consensus to pass, then saying “you need to keep
> discussing until consensus is reached” seems like it could be abused by
> someone who was just willing to not accept a verdict and continues to push,
> right? And if someone were to walk away saying “I don’t want to discuss
> this any further”, which is fair in that situation, then they’re the “bad
> guy”? While it sounds like a noble persuit, I just feel like this could be
> abused.
>
> On Mon, Oct 29, 2018 at 5:53 PM Carin Meier  wrote:
>
> > Chris,
> >
> > Is there are rewording that you would find more acceptable? Again, we can
> > have more time to edit and revise the document. There is not a time limit
> > on this. I might have been too hasty to start the vote thinking the
> > discussion was wrapped up.
> >
> > - Carin
> >
> > On Mon, Oct 29, 2018 at 8:50 PM Chris Olivier 
> > wrote:
> >
> > > or another example if something is downvoted, this also implies that
> > after
> > > a vote is over, it’s approprorate to continue pushing the subject
> trying
> > to
> > > just wear everyone down even though the outcome is clear. We’ve seen
> this
> > > before, actually.
> > >
> > > On Mon, Oct 29, 2018 at 5:41 PM Chris Olivier 
> > > wrote:
> > >
> > > > -1 “strive to meet consensus”? This seems to imply the consensus is
> the
> > > > natural expected state. So in the case where someone submits that we
> > > should
> > > > start a nuclear war, then our bylaws would state that we should all
> try
> > > to
> > > > agree to start a nuclear war.
> > > >
> > > > On Mon, Oct 29, 2018 at 4:41 PM Tianqi Chen 
> wrote:
> > > >
> > > >> Hi Carin:
> > > >> Sorry for the last minute request, but given the way we write
> down
> > > the
> > > >> PMC, committer privileges, I feel we need to add an additional line:
> > > >>
> > > >>- "PMC/committer should strive to be diplomatic and reach
> consensus
> > > >> with
> > > >> discussion when possible."
> > > >>
> > > >>Since I don't really want us to give an impression of abusing
> veto
> > > >> rights.
> > > >>
> > > >> Thanks!
> > > >> Tianqi
> > > >>
> > > >> On Mon, Oct 29, 2018 at 3:47 PM Carin Meier 
> > > wrote:
> > > >>
> > > >> > This vote is to adopt the document
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > > >> > to replace the current document
> > > >> >
> > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > > >> >
> > > >> > The dev discussion thread is here
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
> > > >> >
> > > >> > The vote will be a procedural issue vote as defined
> > > >> > https://www.apache.org/foundation/voting.html
> > > >> >
> > > >> > Votes on procedural issues follow the common format of majority
> rule
> > > >> unless
> > > >> > otherwise stated. That is, if there are more favourable votes than
> > > >> > unfavourable ones, the issue is considered to have passed --
> > > regardless
> > > >> of
> > > >> > the number of votes in each category. (If the number of votes
> seems
> > > too
> > > >> > small to be representative of a community consensus, the issue is
> > > >> typically
> > > >> > not pursued. However, see the description of lazy consensus
> > > >> > 
> for a
> > > >> > modifying factor.)
> > > >> >
> > > >> > The vote will run until Friday Nov 2nd at 6:00 am EST
> > > >> >
> > > >> > Thanks,
> > > >> > Carin
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

well, if something needs consensus to pass, then saying “you need to keep
discussing until consensus is reached” seems like it could be abused by
someone who was just willing to not accept a verdict and continues to push,
right? And if someone were to walk away saying “I don’t want to discuss
this any further”, which is fair in that situation, then they’re the “bad
guy”? While it sounds like a noble persuit, I just feel like this could be
abused.

On Mon, Oct 29, 2018 at 5:53 PM Carin Meier  wrote:

> Chris,
>
> Is there are rewording that you would find more acceptable? Again, we can
> have more time to edit and revise the document. There is not a time limit
> on this. I might have been too hasty to start the vote thinking the
> discussion was wrapped up.
>
> - Carin
>
> On Mon, Oct 29, 2018 at 8:50 PM Chris Olivier 
> wrote:
>
> > or another example if something is downvoted, this also implies that
> after
> > a vote is over, it’s approprorate to continue pushing the subject trying
> to
> > just wear everyone down even though the outcome is clear. We’ve seen this
> > before, actually.
> >
> > On Mon, Oct 29, 2018 at 5:41 PM Chris Olivier 
> > wrote:
> >
> > > -1 “strive to meet consensus”? This seems to imply the consensus is the
> > > natural expected state. So in the case where someone submits that we
> > should
> > > start a nuclear war, then our bylaws would state that we should all try
> > to
> > > agree to start a nuclear war.
> > >
> > > On Mon, Oct 29, 2018 at 4:41 PM Tianqi Chen  wrote:
> > >
> > >> Hi Carin:
> > >> Sorry for the last minute request, but given the way we write down
> > the
> > >> PMC, committer privileges, I feel we need to add an additional line:
> > >>
> > >>- "PMC/committer should strive to be diplomatic and reach consensus
> > >> with
> > >> discussion when possible."
> > >>
> > >>Since I don't really want us to give an impression of abusing veto
> > >> rights.
> > >>
> > >> Thanks!
> > >> Tianqi
> > >>
> > >> On Mon, Oct 29, 2018 at 3:47 PM Carin Meier 
> > wrote:
> > >>
> > >> > This vote is to adopt the document
> > >> >
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > >> > to replace the current document
> > >> >
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > >> >
> > >> > The dev discussion thread is here
> > >> >
> > >> >
> > >>
> >
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
> > >> >
> > >> > The vote will be a procedural issue vote as defined
> > >> > https://www.apache.org/foundation/voting.html
> > >> >
> > >> > Votes on procedural issues follow the common format of majority rule
> > >> unless
> > >> > otherwise stated. That is, if there are more favourable votes than
> > >> > unfavourable ones, the issue is considered to have passed --
> > regardless
> > >> of
> > >> > the number of votes in each category. (If the number of votes seems
> > too
> > >> > small to be representative of a community consensus, the issue is
> > >> typically
> > >> > not pursued. However, see the description of lazy consensus
> > >> >  for a
> > >> > modifying factor.)
> > >> >
> > >> > The vote will run until Friday Nov 2nd at 6:00 am EST
> > >> >
> > >> > Thanks,
> > >> > Carin
> > >> >
> > >>
> > >
> >
>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

2018-10-29 Thread Naveen Swamy

May be we can adopt this.
https://struts.apache.org/bylaws.html#voting



> On Oct 29, 2018, at 5:52 PM, Carin Meier  wrote:
> 
> Chris,
> 
> Is there are rewording that you would find more acceptable? Again, we can
> have more time to edit and revise the document. There is not a time limit
> on this. I might have been too hasty to start the vote thinking the
> discussion was wrapped up.
> 
> - Carin
> 
>> On Mon, Oct 29, 2018 at 8:50 PM Chris Olivier  wrote:
>> 
>> or another example if something is downvoted, this also implies that after
>> a vote is over, it’s approprorate to continue pushing the subject trying to
>> just wear everyone down even though the outcome is clear. We’ve seen this
>> before, actually.
>> 
>> On Mon, Oct 29, 2018 at 5:41 PM Chris Olivier 
>> wrote:
>> 
>>> -1 “strive to meet consensus”? This seems to imply the consensus is the
>>> natural expected state. So in the case where someone submits that we
>> should
>>> start a nuclear war, then our bylaws would state that we should all try
>> to
>>> agree to start a nuclear war.
>>> 
 On Mon, Oct 29, 2018 at 4:41 PM Tianqi Chen  wrote:
 
 Hi Carin:
Sorry for the last minute request, but given the way we write down
>> the
 PMC, committer privileges, I feel we need to add an additional line:
 
   - "PMC/committer should strive to be diplomatic and reach consensus
 with
 discussion when possible."
 
   Since I don't really want us to give an impression of abusing veto
 rights.
 
 Thanks!
 Tianqi
 
 On Mon, Oct 29, 2018 at 3:47 PM Carin Meier 
>> wrote:
 
> This vote is to adopt the document
> 
> 
 
>> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> to replace the current document
> 
>> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> 
> The dev discussion thread is here
> 
> 
 
>> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
> 
> The vote will be a procedural issue vote as defined
> https://www.apache.org/foundation/voting.html
> 
> Votes on procedural issues follow the common format of majority rule
 unless
> otherwise stated. That is, if there are more favourable votes than
> unfavourable ones, the issue is considered to have passed --
>> regardless
 of
> the number of votes in each category. (If the number of votes seems
>> too
> small to be representative of a community consensus, the issue is
 typically
> not pursued. However, see the description of lazy consensus
>  for a
> modifying factor.)
> 
> The vote will run until Friday Nov 2nd at 6:00 am EST
> 
> Thanks,
> Carin
> 
 
>>> 
>>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

-0 but keep it in if you want

On Mon, Oct 29, 2018 at 5:50 PM Chris Olivier  wrote:

> or another example if something is downvoted, this also implies that after
> a vote is over, it’s approprorate to continue pushing the subject trying to
> just wear everyone down even though the outcome is clear. We’ve seen this
> before, actually.
>
> On Mon, Oct 29, 2018 at 5:41 PM Chris Olivier 
> wrote:
>
>> -1 “strive to meet consensus”? This seems to imply the consensus is the
>> natural expected state. So in the case where someone submits that we should
>> start a nuclear war, then our bylaws would state that we should all try to
>> agree to start a nuclear war.
>>
>> On Mon, Oct 29, 2018 at 4:41 PM Tianqi Chen  wrote:
>>
>>> Hi Carin:
>>> Sorry for the last minute request, but given the way we write down
>>> the
>>> PMC, committer privileges, I feel we need to add an additional line:
>>>
>>>- "PMC/committer should strive to be diplomatic and reach consensus
>>> with
>>> discussion when possible."
>>>
>>>Since I don't really want us to give an impression of abusing veto
>>> rights.
>>>
>>> Thanks!
>>> Tianqi
>>>
>>> On Mon, Oct 29, 2018 at 3:47 PM Carin Meier 
>>> wrote:
>>>
>>> > This vote is to adopt the document
>>> >
>>> >
>>> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
>>> > to replace the current document
>>> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>>> >
>>> > The dev discussion thread is here
>>> >
>>> >
>>> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
>>> >
>>> > The vote will be a procedural issue vote as defined
>>> > https://www.apache.org/foundation/voting.html
>>> >
>>> > Votes on procedural issues follow the common format of majority rule
>>> unless
>>> > otherwise stated. That is, if there are more favourable votes than
>>> > unfavourable ones, the issue is considered to have passed --
>>> regardless of
>>> > the number of votes in each category. (If the number of votes seems too
>>> > small to be representative of a community consensus, the issue is
>>> typically
>>> > not pursued. However, see the description of lazy consensus
>>> >  for a
>>> > modifying factor.)
>>> >
>>> > The vote will run until Friday Nov 2nd at 6:00 am EST
>>> >
>>> > Thanks,
>>> > Carin
>>> >
>>>
>>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

Chris,

Is there are rewording that you would find more acceptable? Again, we can
have more time to edit and revise the document. There is not a time limit
on this. I might have been too hasty to start the vote thinking the
discussion was wrapped up.

- Carin

On Mon, Oct 29, 2018 at 8:50 PM Chris Olivier  wrote:

> or another example if something is downvoted, this also implies that after
> a vote is over, it’s approprorate to continue pushing the subject trying to
> just wear everyone down even though the outcome is clear. We’ve seen this
> before, actually.
>
> On Mon, Oct 29, 2018 at 5:41 PM Chris Olivier 
> wrote:
>
> > -1 “strive to meet consensus”? This seems to imply the consensus is the
> > natural expected state. So in the case where someone submits that we
> should
> > start a nuclear war, then our bylaws would state that we should all try
> to
> > agree to start a nuclear war.
> >
> > On Mon, Oct 29, 2018 at 4:41 PM Tianqi Chen  wrote:
> >
> >> Hi Carin:
> >> Sorry for the last minute request, but given the way we write down
> the
> >> PMC, committer privileges, I feel we need to add an additional line:
> >>
> >>- "PMC/committer should strive to be diplomatic and reach consensus
> >> with
> >> discussion when possible."
> >>
> >>Since I don't really want us to give an impression of abusing veto
> >> rights.
> >>
> >> Thanks!
> >> Tianqi
> >>
> >> On Mon, Oct 29, 2018 at 3:47 PM Carin Meier 
> wrote:
> >>
> >> > This vote is to adopt the document
> >> >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> >> > to replace the current document
> >> >
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> >> >
> >> > The dev discussion thread is here
> >> >
> >> >
> >>
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
> >> >
> >> > The vote will be a procedural issue vote as defined
> >> > https://www.apache.org/foundation/voting.html
> >> >
> >> > Votes on procedural issues follow the common format of majority rule
> >> unless
> >> > otherwise stated. That is, if there are more favourable votes than
> >> > unfavourable ones, the issue is considered to have passed --
> regardless
> >> of
> >> > the number of votes in each category. (If the number of votes seems
> too
> >> > small to be representative of a community consensus, the issue is
> >> typically
> >> > not pursued. However, see the description of lazy consensus
> >> >  for a
> >> > modifying factor.)
> >> >
> >> > The vote will run until Friday Nov 2nd at 6:00 am EST
> >> >
> >> > Thanks,
> >> > Carin
> >> >
> >>
> >
>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

or another example if something is downvoted, this also implies that after
a vote is over, it’s approprorate to continue pushing the subject trying to
just wear everyone down even though the outcome is clear. We’ve seen this
before, actually.

On Mon, Oct 29, 2018 at 5:41 PM Chris Olivier  wrote:

> -1 “strive to meet consensus”? This seems to imply the consensus is the
> natural expected state. So in the case where someone submits that we should
> start a nuclear war, then our bylaws would state that we should all try to
> agree to start a nuclear war.
>
> On Mon, Oct 29, 2018 at 4:41 PM Tianqi Chen  wrote:
>
>> Hi Carin:
>> Sorry for the last minute request, but given the way we write down the
>> PMC, committer privileges, I feel we need to add an additional line:
>>
>>- "PMC/committer should strive to be diplomatic and reach consensus
>> with
>> discussion when possible."
>>
>>Since I don't really want us to give an impression of abusing veto
>> rights.
>>
>> Thanks!
>> Tianqi
>>
>> On Mon, Oct 29, 2018 at 3:47 PM Carin Meier  wrote:
>>
>> > This vote is to adopt the document
>> >
>> >
>> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
>> > to replace the current document
>> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>> >
>> > The dev discussion thread is here
>> >
>> >
>> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
>> >
>> > The vote will be a procedural issue vote as defined
>> > https://www.apache.org/foundation/voting.html
>> >
>> > Votes on procedural issues follow the common format of majority rule
>> unless
>> > otherwise stated. That is, if there are more favourable votes than
>> > unfavourable ones, the issue is considered to have passed -- regardless
>> of
>> > the number of votes in each category. (If the number of votes seems too
>> > small to be representative of a community consensus, the issue is
>> typically
>> > not pursued. However, see the description of lazy consensus
>> >  for a
>> > modifying factor.)
>> >
>> > The vote will run until Friday Nov 2nd at 6:00 am EST
>> >
>> > Thanks,
>> > Carin
>> >
>>
>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

-1 “strive to meet consensus”? This seems to imply the consensus is the
natural expected state. So in the case where someone submits that we should
start a nuclear war, then our bylaws would state that we should all try to
agree to start a nuclear war.

On Mon, Oct 29, 2018 at 4:41 PM Tianqi Chen  wrote:

> Hi Carin:
> Sorry for the last minute request, but given the way we write down the
> PMC, committer privileges, I feel we need to add an additional line:
>
>- "PMC/committer should strive to be diplomatic and reach consensus with
> discussion when possible."
>
>Since I don't really want us to give an impression of abusing veto
> rights.
>
> Thanks!
> Tianqi
>
> On Mon, Oct 29, 2018 at 3:47 PM Carin Meier  wrote:
>
> > This vote is to adopt the document
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > to replace the current document
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> >
> > The dev discussion thread is here
> >
> >
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
> >
> > The vote will be a procedural issue vote as defined
> > https://www.apache.org/foundation/voting.html
> >
> > Votes on procedural issues follow the common format of majority rule
> unless
> > otherwise stated. That is, if there are more favourable votes than
> > unfavourable ones, the issue is considered to have passed -- regardless
> of
> > the number of votes in each category. (If the number of votes seems too
> > small to be representative of a community consensus, the issue is
> typically
> > not pursued. However, see the description of lazy consensus
> >  for a
> > modifying factor.)
> >
> > The vote will run until Friday Nov 2nd at 6:00 am EST
> >
> > Thanks,
> > Carin
> >
>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

Tianqi - I added it the end of the document.

If anyone feels that they need more time to further discuss/revise the
changes, I'm fine with ending/suspending the current vote and resuming it
in the future to enable more collaboration.

Just let me know.

Best,
Carin

On Mon, Oct 29, 2018 at 7:41 PM Tianqi Chen  wrote:

> Hi Carin:
> Sorry for the last minute request, but given the way we write down the
> PMC, committer privileges, I feel we need to add an additional line:
>
>- "PMC/committer should strive to be diplomatic and reach consensus with
> discussion when possible."
>
>Since I don't really want us to give an impression of abusing veto
> rights.
>
> Thanks!
> Tianqi
>
> On Mon, Oct 29, 2018 at 3:47 PM Carin Meier  wrote:
>
> > This vote is to adopt the document
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > to replace the current document
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> >
> > The dev discussion thread is here
> >
> >
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
> >
> > The vote will be a procedural issue vote as defined
> > https://www.apache.org/foundation/voting.html
> >
> > Votes on procedural issues follow the common format of majority rule
> unless
> > otherwise stated. That is, if there are more favourable votes than
> > unfavourable ones, the issue is considered to have passed -- regardless
> of
> > the number of votes in each category. (If the number of votes seems too
> > small to be representative of a community consensus, the issue is
> typically
> > not pursued. However, see the description of lazy consensus
> >  for a
> > modifying factor.)
> >
> > The vote will run until Friday Nov 2nd at 6:00 am EST
> >
> > Thanks,
> > Carin
> >
>

Security Risk in requests<2.20 (CVE-2018-18074)

2018-10-29 Thread Sheng Zha

See https://github.com/apache/incubator-mxnet/issues/13032

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

Hi Carin:
Sorry for the last minute request, but given the way we write down the
PMC, committer privileges, I feel we need to add an additional line:

   - "PMC/committer should strive to be diplomatic and reach consensus with
discussion when possible."

   Since I don't really want us to give an impression of abusing veto
rights.

Thanks!
Tianqi

On Mon, Oct 29, 2018 at 3:47 PM Carin Meier  wrote:

> This vote is to adopt the document
>
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> to replace the current document
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>
> The dev discussion thread is here
>
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
>
> The vote will be a procedural issue vote as defined
> https://www.apache.org/foundation/voting.html
>
> Votes on procedural issues follow the common format of majority rule unless
> otherwise stated. That is, if there are more favourable votes than
> unfavourable ones, the issue is considered to have passed -- regardless of
> the number of votes in each category. (If the number of votes seems too
> small to be representative of a community consensus, the issue is typically
> not pursued. However, see the description of lazy consensus
>  for a
> modifying factor.)
>
> The vote will run until Friday Nov 2nd at 6:00 am EST
>
> Thanks,
> Carin
>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

2018-10-29 Thread Yuan Tang

+1

On Mon, Oct 29, 2018 at 7:28 PM Tianqi Chen 
wrote:

> +1
>
> Tianqi
>
> On Mon, Oct 29, 2018 at 3:47 PM Carin Meier  wrote:
>
> > This vote is to adopt the document
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > to replace the current document
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> >
> > The dev discussion thread is here
> >
> >
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
> >
> > The vote will be a procedural issue vote as defined
> > https://www.apache.org/foundation/voting.html
> >
> > Votes on procedural issues follow the common format of majority rule
> unless
> > otherwise stated. That is, if there are more favourable votes than
> > unfavourable ones, the issue is considered to have passed -- regardless
> of
> > the number of votes in each category. (If the number of votes seems too
> > small to be representative of a community consensus, the issue is
> typically
> > not pursued. However, see the description of lazy consensus
> >  for a
> > modifying factor.)
> >
> > The vote will run until Friday Nov 2nd at 6:00 am EST
> >
> > Thanks,
> > Carin
> >
>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

+1

Tianqi

On Mon, Oct 29, 2018 at 3:47 PM Carin Meier  wrote:

> This vote is to adopt the document
>
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> to replace the current document
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>
> The dev discussion thread is here
>
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
>
> The vote will be a procedural issue vote as defined
> https://www.apache.org/foundation/voting.html
>
> Votes on procedural issues follow the common format of majority rule unless
> otherwise stated. That is, if there are more favourable votes than
> unfavourable ones, the issue is considered to have passed -- regardless of
> the number of votes in each category. (If the number of votes seems too
> small to be representative of a community consensus, the issue is typically
> not pursued. However, see the description of lazy consensus
>  for a
> modifying factor.)
>
> The vote will run until Friday Nov 2nd at 6:00 am EST
>
> Thanks,
> Carin
>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

2018-10-29 Thread kellen sunderland

+1 non-binding.  As mentioned in various threads, this model should be much
more scalable.  I like the idea of hierarchies of contributors on the
project.

On Mon, Oct 29, 2018 at 3:47 PM Carin Meier  wrote:

> This vote is to adopt the document
>
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> to replace the current document
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>
> The dev discussion thread is here
>
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
>
> The vote will be a procedural issue vote as defined
> https://www.apache.org/foundation/voting.html
>
> Votes on procedural issues follow the common format of majority rule unless
> otherwise stated. That is, if there are more favourable votes than
> unfavourable ones, the issue is considered to have passed -- regardless of
> the number of votes in each category. (If the number of votes seems too
> small to be representative of a community consensus, the issue is typically
> not pursued. However, see the description of lazy consensus
>  for a
> modifying factor.)
>
> The vote will run until Friday Nov 2nd at 6:00 am EST
>
> Thanks,
> Carin
>

[VOTE] - Adopt "Become a Committer and PPMC Member" Document

This vote is to adopt the document
https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
to replace the current document
https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer

The dev discussion thread is here
https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E

The vote will be a procedural issue vote as defined
https://www.apache.org/foundation/voting.html

Votes on procedural issues follow the common format of majority rule unless
otherwise stated. That is, if there are more favourable votes than
unfavourable ones, the issue is considered to have passed -- regardless of
the number of votes in each category. (If the number of votes seems too
small to be representative of a community consensus, the issue is typically
not pursued. However, see the description of lazy consensus
 for a
modifying factor.)

The vote will run until Friday Nov 2nd at 6:00 am EST

Thanks,
Carin

Re: Apache MXNet Scala nightly-build now available on Apache Nexus

Fantastic! This is going to be great for the Clojure MXNet users as well.

On Mon, Oct 29, 2018 at 1:39 PM YiZhi Liu  wrote:

> Hi,
>
>
>
> I am happy to announce that the availability of the experimental
> nightly-build Scala package on Maven in Nexus. The nightly-builds,
> currently published as 1.3.1-SNAPSHOT version, include the latest changes
> from the master branch from apache/incubator-mxnet GitHub repo and refresh
> every day. Furthermore, we completely overhauled the MXNet library shipped
> inside and adopted the binary build logic used for Python pip, so now Scala
> users can also enjoy the portable MXNet with fully loaded features.
> Currently, the supported artifacts are:
>
> - mxnet-full_2.11-linux-x86_64-cpu (Linux-CPU)
>
> - mxnet-full_2.11-linux-x86_64-gpu (Linux-GPU, CUDA 9.0)
>
> - mxnet-full_2.11-osx-x86_64-cpu (OSX-CPU)
>
>
>
> FAQ:
>
> - What's new in the nightly Scala packages compared to the previous Scala
> Maven artifacts?
>
> Most notably, better usability, more supported features, and better
> platform compatibility. The new packages now support Ubuntu 14.04 and
> Amazon Linux and support the same broad set of features as the existing pip
> packages. Besides, users are no longer required to install all the
> dependencies to use the nightly Scala packages as the included MXNet
> libraries are fully loaded. For the list of supported platforms and
> features, see [1].
>
>
>
> - What's different in the build approach compared to what's in the previous
> Scala Maven packages?
>
> The previous Scala Maven packages (1.2, 1.2.1, 1.3) were built with the
> same build commands that regular users would use when building from source
> [2]. This naive approach limits the compatibility to only similar
> environments as where the packages were built (which was Ubuntu 16.04 for
> Linux, and OSX 10.13 for OSX). As a result, users cannot use it on more
> CentOS or Amazon Linux and may suffer the problem of mismatching of
> dependency versions due to the difference in their environment.
>
> On the other hand, Python users have long been enjoying portable and fully
> loaded MXNet packages from pip. The MXNet libraries in pip packages are
> built in more controlled environments with compatibility in mind.
> Dependencies for extended features are statically linked and masked so that
> no additional steps are needed.
>
> Now, in the new Scala nightly packages, the same approach as pip is used
> for building the MXNet library so that the Scala users can benefit from the
> same great features.
>
>
>
> - How do I get the new nightly packages?
>
> You can find the packages on Apache (Snapshots) repository [3] including
> pom files and jars, which you can download and add to your projects.
> Alternatively, you can configure your pom.xml to use the Maven repository.
> Remember to add repository config:
>
> 
>
>   
>
> Apache Snapshot
>
> https://repository.apache.org/content/groups/snapshots
>
>   
>
> 
>
>
>
> - What's the support level of the Scala nightly packages?
>
> This package is currently experimental, so use at your own risk. While the
> first nightly packages are already manually verified on several platforms,
> and the automated publish pipeline runs unit tests and integration tests on
> OSX and Ubuntu 14.04 before publishing, the testing is currently limited.
>
>
>
> - How can I help?
>
> We call on all MXNet Scala community to test out the new nightly packages.
>
>
>
> - I found a problem in using the package. What should I do?
>
> Please report this in the Github issue in [1].
>
>
>
> - What's next?
>
> There are several more things to be done:
>
> 1. We are adding more comprehensive support for GPU versions for different
> CUDA versions.
>
> 2. We are adding more tests on more platforms. We are currently examining
> the MXNet's Jenkins CI solution for supporting more platforms.
>
> 3. As we recognize that the build logic benefits the community, we plan to
> open source the build scripts in the mxnet main repo. See progress at [5].
>
>
>
> Qing Lan, Zach Kimberg, Sheng Zha, and I worked together to make this
> happen. Thanks to Sheng Zha for sharing the pip build logic, and for
> building the automated publishing pipelines. Special thanks to Qing and
> Zach for sharing their expertise in Scala with Sheng and guiding and
> supporting him locally for this milestone.
>
>
>
> [1] https://github.com/apache/incubator-mxnet/issues/8671
>
> [2]
>
> https://github.com/apache/incubator-mxnet/blob/master/scala-package/dev/compile-mxnet-backend.sh#L59-L105
>
> [3]
>
> https://repository.apache.org/#nexus-search;gav~org.apache.mxnet~~1.3.1-SNAPSHOT~~
>
> [4] https://maven.apache.org/repository-management.html
>
> [5] https://github.com/apache/incubator-mxnet/projects/13
>

Re: request slack access

2018-10-29 Thread Steffen Rochel

Hi Yao - welcome to the project. Added you to slack.
Regards,
Steffen

On Mon, Oct 29, 2018 at 12:47 PM yao zhao  wrote:

> thanks
> yao
>

request slack access

2018-10-29 Thread yao zhao

thanks
yao

Re: Apache MXNet Scala nightly-build now available on Apache Nexus

This is a great step for the community

Tianqi

On Mon, Oct 29, 2018 at 10:39 AM YiZhi Liu  wrote:

> Hi,
>
>
>
> I am happy to announce that the availability of the experimental
> nightly-build Scala package on Maven in Nexus. The nightly-builds,
> currently published as 1.3.1-SNAPSHOT version, include the latest changes
> from the master branch from apache/incubator-mxnet GitHub repo and refresh
> every day. Furthermore, we completely overhauled the MXNet library shipped
> inside and adopted the binary build logic used for Python pip, so now Scala
> users can also enjoy the portable MXNet with fully loaded features.
> Currently, the supported artifacts are:
>
> - mxnet-full_2.11-linux-x86_64-cpu (Linux-CPU)
>
> - mxnet-full_2.11-linux-x86_64-gpu (Linux-GPU, CUDA 9.0)
>
> - mxnet-full_2.11-osx-x86_64-cpu (OSX-CPU)
>
>
>
> FAQ:
>
> - What's new in the nightly Scala packages compared to the previous Scala
> Maven artifacts?
>
> Most notably, better usability, more supported features, and better
> platform compatibility. The new packages now support Ubuntu 14.04 and
> Amazon Linux and support the same broad set of features as the existing pip
> packages. Besides, users are no longer required to install all the
> dependencies to use the nightly Scala packages as the included MXNet
> libraries are fully loaded. For the list of supported platforms and
> features, see [1].
>
>
>
> - What's different in the build approach compared to what's in the previous
> Scala Maven packages?
>
> The previous Scala Maven packages (1.2, 1.2.1, 1.3) were built with the
> same build commands that regular users would use when building from source
> [2]. This naive approach limits the compatibility to only similar
> environments as where the packages were built (which was Ubuntu 16.04 for
> Linux, and OSX 10.13 for OSX). As a result, users cannot use it on more
> CentOS or Amazon Linux and may suffer the problem of mismatching of
> dependency versions due to the difference in their environment.
>
> On the other hand, Python users have long been enjoying portable and fully
> loaded MXNet packages from pip. The MXNet libraries in pip packages are
> built in more controlled environments with compatibility in mind.
> Dependencies for extended features are statically linked and masked so that
> no additional steps are needed.
>
> Now, in the new Scala nightly packages, the same approach as pip is used
> for building the MXNet library so that the Scala users can benefit from the
> same great features.
>
>
>
> - How do I get the new nightly packages?
>
> You can find the packages on Apache (Snapshots) repository [3] including
> pom files and jars, which you can download and add to your projects.
> Alternatively, you can configure your pom.xml to use the Maven repository.
> Remember to add repository config:
>
> 
>
>   
>
> Apache Snapshot
>
> https://repository.apache.org/content/groups/snapshots
>
>   
>
> 
>
>
>
> - What's the support level of the Scala nightly packages?
>
> This package is currently experimental, so use at your own risk. While the
> first nightly packages are already manually verified on several platforms,
> and the automated publish pipeline runs unit tests and integration tests on
> OSX and Ubuntu 14.04 before publishing, the testing is currently limited.
>
>
>
> - How can I help?
>
> We call on all MXNet Scala community to test out the new nightly packages.
>
>
>
> - I found a problem in using the package. What should I do?
>
> Please report this in the Github issue in [1].
>
>
>
> - What's next?
>
> There are several more things to be done:
>
> 1. We are adding more comprehensive support for GPU versions for different
> CUDA versions.
>
> 2. We are adding more tests on more platforms. We are currently examining
> the MXNet's Jenkins CI solution for supporting more platforms.
>
> 3. As we recognize that the build logic benefits the community, we plan to
> open source the build scripts in the mxnet main repo. See progress at [5].
>
>
>
> Qing Lan, Zach Kimberg, Sheng Zha, and I worked together to make this
> happen. Thanks to Sheng Zha for sharing the pip build logic, and for
> building the automated publishing pipelines. Special thanks to Qing and
> Zach for sharing their expertise in Scala with Sheng and guiding and
> supporting him locally for this milestone.
>
>
>
> [1] https://github.com/apache/incubator-mxnet/issues/8671
>
> [2]
>
> https://github.com/apache/incubator-mxnet/blob/master/scala-package/dev/compile-mxnet-backend.sh#L59-L105
>
> [3]
>
> https://repository.apache.org/#nexus-search;gav~org.apache.mxnet~~1.3.1-SNAPSHOT~~
>
> [4] https://maven.apache.org/repository-management.html
>
> [5] https://github.com/apache/incubator-mxnet/projects/13
>

Re: Apache MXNet Scala nightly-build now available on Apache Nexus

2018-10-29 Thread Ziheng Jiang

Nice work! It is quite helpful for deployment of MXNet Scala!

On Mon, Oct 29, 2018 at 10:39 AM YiZhi Liu  wrote:

> Hi,
>
>
>
> I am happy to announce that the availability of the experimental
> nightly-build Scala package on Maven in Nexus. The nightly-builds,
> currently published as 1.3.1-SNAPSHOT version, include the latest changes
> from the master branch from apache/incubator-mxnet GitHub repo and refresh
> every day. Furthermore, we completely overhauled the MXNet library shipped
> inside and adopted the binary build logic used for Python pip, so now Scala
> users can also enjoy the portable MXNet with fully loaded features.
> Currently, the supported artifacts are:
>
> - mxnet-full_2.11-linux-x86_64-cpu (Linux-CPU)
>
> - mxnet-full_2.11-linux-x86_64-gpu (Linux-GPU, CUDA 9.0)
>
> - mxnet-full_2.11-osx-x86_64-cpu (OSX-CPU)
>
>
>
> FAQ:
>
> - What's new in the nightly Scala packages compared to the previous Scala
> Maven artifacts?
>
> Most notably, better usability, more supported features, and better
> platform compatibility. The new packages now support Ubuntu 14.04 and
> Amazon Linux and support the same broad set of features as the existing pip
> packages. Besides, users are no longer required to install all the
> dependencies to use the nightly Scala packages as the included MXNet
> libraries are fully loaded. For the list of supported platforms and
> features, see [1].
>
>
>
> - What's different in the build approach compared to what's in the previous
> Scala Maven packages?
>
> The previous Scala Maven packages (1.2, 1.2.1, 1.3) were built with the
> same build commands that regular users would use when building from source
> [2]. This naive approach limits the compatibility to only similar
> environments as where the packages were built (which was Ubuntu 16.04 for
> Linux, and OSX 10.13 for OSX). As a result, users cannot use it on more
> CentOS or Amazon Linux and may suffer the problem of mismatching of
> dependency versions due to the difference in their environment.
>
> On the other hand, Python users have long been enjoying portable and fully
> loaded MXNet packages from pip. The MXNet libraries in pip packages are
> built in more controlled environments with compatibility in mind.
> Dependencies for extended features are statically linked and masked so that
> no additional steps are needed.
>
> Now, in the new Scala nightly packages, the same approach as pip is used
> for building the MXNet library so that the Scala users can benefit from the
> same great features.
>
>
>
> - How do I get the new nightly packages?
>
> You can find the packages on Apache (Snapshots) repository [3] including
> pom files and jars, which you can download and add to your projects.
> Alternatively, you can configure your pom.xml to use the Maven repository.
> Remember to add repository config:
>
> 
>
>   
>
> Apache Snapshot
>
> https://repository.apache.org/content/groups/snapshots
>
>   
>
> 
>
>
>
> - What's the support level of the Scala nightly packages?
>
> This package is currently experimental, so use at your own risk. While the
> first nightly packages are already manually verified on several platforms,
> and the automated publish pipeline runs unit tests and integration tests on
> OSX and Ubuntu 14.04 before publishing, the testing is currently limited.
>
>
>
> - How can I help?
>
> We call on all MXNet Scala community to test out the new nightly packages.
>
>
>
> - I found a problem in using the package. What should I do?
>
> Please report this in the Github issue in [1].
>
>
>
> - What's next?
>
> There are several more things to be done:
>
> 1. We are adding more comprehensive support for GPU versions for different
> CUDA versions.
>
> 2. We are adding more tests on more platforms. We are currently examining
> the MXNet's Jenkins CI solution for supporting more platforms.
>
> 3. As we recognize that the build logic benefits the community, we plan to
> open source the build scripts in the mxnet main repo. See progress at [5].
>
>
>
> Qing Lan, Zach Kimberg, Sheng Zha, and I worked together to make this
> happen. Thanks to Sheng Zha for sharing the pip build logic, and for
> building the automated publishing pipelines. Special thanks to Qing and
> Zach for sharing their expertise in Scala with Sheng and guiding and
> supporting him locally for this milestone.
>
>
>
> [1] https://github.com/apache/incubator-mxnet/issues/8671
>
> [2]
>
> https://github.com/apache/incubator-mxnet/blob/master/scala-package/dev/compile-mxnet-backend.sh#L59-L105
>
> [3]
>
> https://repository.apache.org/#nexus-search;gav~org.apache.mxnet~~1.3.1-SNAPSHOT~~
>
> [4] https://maven.apache.org/repository-management.html
>
> [5] https://github.com/apache/incubator-mxnet/projects/13
>
-- 
Ziheng Jiang
Fudan University | Computer Science

Re: [DISCUSS] - Revisions to Committer Criteria

2018-10-29 Thread Yuan Tang

Thanks Kellen for the clarification. The revised version looks good to me.

On Mon, Oct 29, 2018 at 1:40 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Forgot to answer your second question "How many votes are required by PMCs
> before the formal release can happen? Is this considered community-related
> decision as well, e.g. PMC vetos are binding?"
> Answer "Votes on whether a package is ready to be released use majority
> approval 
> --
> i.e. at least three PMC members must vote affirmatively for release, and
> there must be more positive than negative votes. Releases may not be
> vetoed. Generally
> the community will cancel the release vote if anyone identifies serious
> problems, but in most cases the ultimate decision, lies with the individual
> serving as release manager. The specifics of the process may vary from
> project to project, but the 'minimum quorum of three +1 votes' rule is
> universal."
> from: https://www.apache.org/foundation/voting.html
>
> On Mon, Oct 29, 2018 at 10:38 AM kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
>
> > I believe the wording _must_ comes from the fact that the PMC (as a body)
> > must have a formal vote for a release, otherwise the release will not
> > happen.  I don't believe it means every PMC member is required to vote on
> > the release.  I can see where the confusion comes from, but also feel the
> > wording is correct.
> >
> > On Mon, Oct 29, 2018 at 8:53 AM Yuan Tang 
> wrote:
> >
> >> On Sun, Oct 28, 2018 at 11:12 PM Naveen Swamy 
> wrote:
> >>
> >> > I added clarifying sections to explicitly call out committers/PMC
> >> > privileges. Please review.
> >> >
> >> > Pasting here for convenience
> >> > Committer Privileges
> >> >
> >> >- Committers have write access to the code repository.
> >> >- Committers have an @apache.org email address.
> >> >- Committers can make short-term decisions for the project,
> approving
> >> >and merging pull requests.
> >> >- Committer Vote is *NOT* considered *binding* thus the vote you
> >> cast do
> >> >not have *Veto* on issues that require consensus.
> >> >- Committer's can request changes on Pull Requests but it does not
> >> >constitute Veto, PMC can agree to approve or reject requested
> >> changes.
> >> >
> >> > PMC Privileges
> >> >
> >> >- PMC makes the long-term decisions with regard to the project.
> >> >- PMC members have write access to the code repository.
> >> >- PMC members have @apache.org email address.
> >> >- PMC has access to private@ email list
> >> >- PMC has the right to vote for the community-related decisions,
> PMC
> >> >Votes are *binding*.
> >> >- PMC has the right to propose active users for committership.
> >> >- PMC must vote on any formal release of the project's software
> >> product.
> >> >
> >> Could you clarify on this (I don't think you meant "PMC *must* vote")?
> How
> >> many votes are required by PMCs before the formal release can happen? Is
> >> this considered community-related decision as well, e.g. PMC vetos are
> >> binding?
> >>
> >>
> >> >
> >> >
> >> > All, I suggest you review the proposal and if there is any concern
> >> please
> >> > voice it here before this goes out for voting.
> >> >
> >> >
> >> > On Sun, Oct 28, 2018 at 8:04 AM Carin Meier 
> >> wrote:
> >> >
> >> > > I plan to start a vote on the adopting
> >> > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> >> > > to
> >> > > replace our current document
> >> > >
> >> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> >> > > tomorrow
> >> > > (Monday).
> >> > >
> >> > > - Carin
> >> > >
> >> > > On Thu, Oct 25, 2018 at 8:32 AM Carin Meier 
> >> > wrote:
> >> > >
> >> > > > Thanks for publishing the notes and also thanks everyone for
> >> providing
> >> > > > valuable feedback and discussion.
> >> > > >
> >> > > > I encourage everyone that has ideas for improvement to the
> document
> >> to
> >> > > > feel free to edit and revise. If you need a login to the wiki,
> >> please
> >> > > just
> >> > > > ask.
> >> > > >
> >> > > > Also, while editing, please keep in mind that the intent is to
> have
> >> a
> >> > > vote
> >> > > > on adopting the new
> >> > > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> >> > > > to replace our current document
> >> > > >
> >> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> >> > > > before a vote on separating levels of committer and PPMC as a
> >> process.
> >> > > So,
> >> > > > if possible, adopting wording that would work in either outcome of
> >> that
> >> > > > vote.
> >> > > >
> >> > > > On the subject of voting, I was thinking of starting a vote on
> >> Friday,
> >> > > bu

Re: [DISCUSS] - Revisions to Committer Criteria

2018-10-29 Thread kellen sunderland

Forgot to answer your second question "How many votes are required by PMCs
before the formal release can happen? Is this considered community-related
decision as well, e.g. PMC vetos are binding?"
Answer "Votes on whether a package is ready to be released use majority
approval  --
i.e. at least three PMC members must vote affirmatively for release, and
there must be more positive than negative votes. Releases may not be
vetoed. Generally
the community will cancel the release vote if anyone identifies serious
problems, but in most cases the ultimate decision, lies with the individual
serving as release manager. The specifics of the process may vary from
project to project, but the 'minimum quorum of three +1 votes' rule is
universal."
from: https://www.apache.org/foundation/voting.html

On Mon, Oct 29, 2018 at 10:38 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> I believe the wording _must_ comes from the fact that the PMC (as a body)
> must have a formal vote for a release, otherwise the release will not
> happen.  I don't believe it means every PMC member is required to vote on
> the release.  I can see where the confusion comes from, but also feel the
> wording is correct.
>
> On Mon, Oct 29, 2018 at 8:53 AM Yuan Tang  wrote:
>
>> On Sun, Oct 28, 2018 at 11:12 PM Naveen Swamy  wrote:
>>
>> > I added clarifying sections to explicitly call out committers/PMC
>> > privileges. Please review.
>> >
>> > Pasting here for convenience
>> > Committer Privileges
>> >
>> >- Committers have write access to the code repository.
>> >- Committers have an @apache.org email address.
>> >- Committers can make short-term decisions for the project, approving
>> >and merging pull requests.
>> >- Committer Vote is *NOT* considered *binding* thus the vote you
>> cast do
>> >not have *Veto* on issues that require consensus.
>> >- Committer's can request changes on Pull Requests but it does not
>> >constitute Veto, PMC can agree to approve or reject requested
>> changes.
>> >
>> > PMC Privileges
>> >
>> >- PMC makes the long-term decisions with regard to the project.
>> >- PMC members have write access to the code repository.
>> >- PMC members have @apache.org email address.
>> >- PMC has access to private@ email list
>> >- PMC has the right to vote for the community-related decisions, PMC
>> >Votes are *binding*.
>> >- PMC has the right to propose active users for committership.
>> >- PMC must vote on any formal release of the project's software
>> product.
>> >
>> Could you clarify on this (I don't think you meant "PMC *must* vote")? How
>> many votes are required by PMCs before the formal release can happen? Is
>> this considered community-related decision as well, e.g. PMC vetos are
>> binding?
>>
>>
>> >
>> >
>> > All, I suggest you review the proposal and if there is any concern
>> please
>> > voice it here before this goes out for voting.
>> >
>> >
>> > On Sun, Oct 28, 2018 at 8:04 AM Carin Meier 
>> wrote:
>> >
>> > > I plan to start a vote on the adopting
>> > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
>> > > to
>> > > replace our current document
>> > >
>> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>> > > tomorrow
>> > > (Monday).
>> > >
>> > > - Carin
>> > >
>> > > On Thu, Oct 25, 2018 at 8:32 AM Carin Meier 
>> > wrote:
>> > >
>> > > > Thanks for publishing the notes and also thanks everyone for
>> providing
>> > > > valuable feedback and discussion.
>> > > >
>> > > > I encourage everyone that has ideas for improvement to the document
>> to
>> > > > feel free to edit and revise. If you need a login to the wiki,
>> please
>> > > just
>> > > > ask.
>> > > >
>> > > > Also, while editing, please keep in mind that the intent is to have
>> a
>> > > vote
>> > > > on adopting the new
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
>> > > > to replace our current document
>> > > >
>> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>> > > > before a vote on separating levels of committer and PPMC as a
>> process.
>> > > So,
>> > > > if possible, adopting wording that would work in either outcome of
>> that
>> > > > vote.
>> > > >
>> > > > On the subject of voting, I was thinking of starting a vote on
>> Friday,
>> > > but
>> > > > will delay that until the active discussions and revisions are
>> > complete.
>> > > >
>> > > > Best,
>> > > > Carin
>> > > >
>> > > > On Thu, Oct 25, 2018 at 6:39 AM Pedro Larroy <
>> > > pedro.larroy.li...@gmail.com>
>> > > > wrote:
>> > > >
>> > > >> This is the first hangout that I was able to attend, I liked the
>> > format
>> > > >> and
>> > > >> found them valuable. Thanks for organizing and publishing the

Apache MXNet Scala nightly-build now available on Apache Nexus

2018-10-29 Thread YiZhi Liu

Hi,

I am happy to announce that the availability of the experimental
nightly-build Scala package on Maven in Nexus. The nightly-builds,
currently published as 1.3.1-SNAPSHOT version, include the latest changes
from the master branch from apache/incubator-mxnet GitHub repo and refresh
every day. Furthermore, we completely overhauled the MXNet library shipped
inside and adopted the binary build logic used for Python pip, so now Scala
users can also enjoy the portable MXNet with fully loaded features.
Currently, the supported artifacts are:

- mxnet-full_2.11-linux-x86_64-cpu (Linux-CPU)

- mxnet-full_2.11-linux-x86_64-gpu (Linux-GPU, CUDA 9.0)

- mxnet-full_2.11-osx-x86_64-cpu (OSX-CPU)

FAQ:

- What's new in the nightly Scala packages compared to the previous Scala
Maven artifacts?

Most notably, better usability, more supported features, and better
platform compatibility. The new packages now support Ubuntu 14.04 and
Amazon Linux and support the same broad set of features as the existing pip
packages. Besides, users are no longer required to install all the
dependencies to use the nightly Scala packages as the included MXNet
libraries are fully loaded. For the list of supported platforms and
features, see [1].

- What's different in the build approach compared to what's in the previous
Scala Maven packages?

The previous Scala Maven packages (1.2, 1.2.1, 1.3) were built with the
same build commands that regular users would use when building from source
[2]. This naive approach limits the compatibility to only similar
environments as where the packages were built (which was Ubuntu 16.04 for
Linux, and OSX 10.13 for OSX). As a result, users cannot use it on more
CentOS or Amazon Linux and may suffer the problem of mismatching of
dependency versions due to the difference in their environment.

On the other hand, Python users have long been enjoying portable and fully
loaded MXNet packages from pip. The MXNet libraries in pip packages are
built in more controlled environments with compatibility in mind.
Dependencies for extended features are statically linked and masked so that
no additional steps are needed.

Now, in the new Scala nightly packages, the same approach as pip is used
for building the MXNet library so that the Scala users can benefit from the
same great features.

- How do I get the new nightly packages?

You can find the packages on Apache (Snapshots) repository [3] including
pom files and jars, which you can download and add to your projects.
Alternatively, you can configure your pom.xml to use the Maven repository.
Remember to add repository config:

Apache Snapshot

https://repository.apache.org/content/groups/snapshots

- What's the support level of the Scala nightly packages?

This package is currently experimental, so use at your own risk. While the
first nightly packages are already manually verified on several platforms,
and the automated publish pipeline runs unit tests and integration tests on
OSX and Ubuntu 14.04 before publishing, the testing is currently limited.

- How can I help?

We call on all MXNet Scala community to test out the new nightly packages.

- I found a problem in using the package. What should I do?

Please report this in the Github issue in [1].

- What's next?

There are several more things to be done:

1. We are adding more comprehensive support for GPU versions for different
CUDA versions.

2. We are adding more tests on more platforms. We are currently examining
the MXNet's Jenkins CI solution for supporting more platforms.

3. As we recognize that the build logic benefits the community, we plan to
open source the build scripts in the mxnet main repo. See progress at [5].

Qing Lan, Zach Kimberg, Sheng Zha, and I worked together to make this
happen. Thanks to Sheng Zha for sharing the pip build logic, and for
building the automated publishing pipelines. Special thanks to Qing and
Zach for sharing their expertise in Scala with Sheng and guiding and
supporting him locally for this milestone.

[1] https://github.com/apache/incubator-mxnet/issues/8671

[2]
https://github.com/apache/incubator-mxnet/blob/master/scala-package/dev/compile-mxnet-backend.sh#L59-L105

[3]
https://repository.apache.org/#nexus-search;gav~org.apache.mxnet~~1.3.1-SNAPSHOT~~

[4] https://maven.apache.org/repository-management.html

[5] https://github.com/apache/incubator-mxnet/projects/13

Re: [DISCUSS] - Revisions to Committer Criteria

2018-10-29 Thread kellen sunderland

I believe the wording _must_ comes from the fact that the PMC (as a body)
must have a formal vote for a release, otherwise the release will not
happen.  I don't believe it means every PMC member is required to vote on
the release.  I can see where the confusion comes from, but also feel the
wording is correct.

On Mon, Oct 29, 2018 at 8:53 AM Yuan Tang  wrote:

> On Sun, Oct 28, 2018 at 11:12 PM Naveen Swamy  wrote:
>
> > I added clarifying sections to explicitly call out committers/PMC
> > privileges. Please review.
> >
> > Pasting here for convenience
> > Committer Privileges
> >
> >- Committers have write access to the code repository.
> >- Committers have an @apache.org email address.
> >- Committers can make short-term decisions for the project, approving
> >and merging pull requests.
> >- Committer Vote is *NOT* considered *binding* thus the vote you cast
> do
> >not have *Veto* on issues that require consensus.
> >- Committer's can request changes on Pull Requests but it does not
> >constitute Veto, PMC can agree to approve or reject requested changes.
> >
> > PMC Privileges
> >
> >- PMC makes the long-term decisions with regard to the project.
> >- PMC members have write access to the code repository.
> >- PMC members have @apache.org email address.
> >- PMC has access to private@ email list
> >- PMC has the right to vote for the community-related decisions, PMC
> >Votes are *binding*.
> >- PMC has the right to propose active users for committership.
> >- PMC must vote on any formal release of the project's software
> product.
> >
> Could you clarify on this (I don't think you meant "PMC *must* vote")? How
> many votes are required by PMCs before the formal release can happen? Is
> this considered community-related decision as well, e.g. PMC vetos are
> binding?
>
>
> >
> >
> > All, I suggest you review the proposal and if there is any concern please
> > voice it here before this goes out for voting.
> >
> >
> > On Sun, Oct 28, 2018 at 8:04 AM Carin Meier 
> wrote:
> >
> > > I plan to start a vote on the adopting
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > > to
> > > replace our current document
> > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > > tomorrow
> > > (Monday).
> > >
> > > - Carin
> > >
> > > On Thu, Oct 25, 2018 at 8:32 AM Carin Meier 
> > wrote:
> > >
> > > > Thanks for publishing the notes and also thanks everyone for
> providing
> > > > valuable feedback and discussion.
> > > >
> > > > I encourage everyone that has ideas for improvement to the document
> to
> > > > feel free to edit and revise. If you need a login to the wiki, please
> > > just
> > > > ask.
> > > >
> > > > Also, while editing, please keep in mind that the intent is to have a
> > > vote
> > > > on adopting the new
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > > > to replace our current document
> > > >
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > > > before a vote on separating levels of committer and PPMC as a
> process.
> > > So,
> > > > if possible, adopting wording that would work in either outcome of
> that
> > > > vote.
> > > >
> > > > On the subject of voting, I was thinking of starting a vote on
> Friday,
> > > but
> > > > will delay that until the active discussions and revisions are
> > complete.
> > > >
> > > > Best,
> > > > Carin
> > > >
> > > > On Thu, Oct 25, 2018 at 6:39 AM Pedro Larroy <
> > > pedro.larroy.li...@gmail.com>
> > > > wrote:
> > > >
> > > >> This is the first hangout that I was able to attend, I liked the
> > format
> > > >> and
> > > >> found them valuable. Thanks for organizing and publishing the notes.
> > > >> Looking forward to the next one.
> > > >>
> > > >> Pedro
> > > >>
> > > >> On Thu, Oct 25, 2018 at 6:44 AM Steffen Rochel <
> > steffenroc...@gmail.com
> > > >
> > > >> wrote:
> > > >>
> > > >> > Carin - please see
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Hangout+October+24th+2018+8am+and+5pm+PDT
> > > >> > :
> > > >> > Discussion about committer proposal:
> > > >> >
> > > >> >- Proposal default should be to have separation between
> committer
> > > and
> > > >> >PPMC election
> > > >> >- Criteria are vague, should we add some example persona?
> > > >> >- Spell out privileges of committer and PPMC member
> > > >> >
> > > >> >
> > > >> > Note: I update the project proposal to address first bullet.
> > > >> >
> > > >> > Steffen
> > > >> >
> > > >> >
> > > >> > On Wed, Oct 24, 2018 at 11:29 AM Carin Meier <
> carinme...@gmail.com>
> > > >> wrote:
> > > >> >
> > > >> > > A request to whoever is taking notes at the MXNet Hangouts that
> > are
> > > >> > > occurring today. Could you please rec

Re: [DISCUSS] - Revisions to Committer Criteria

2018-10-29 Thread Yuan Tang

On Sun, Oct 28, 2018 at 11:12 PM Naveen Swamy  wrote:

> I added clarifying sections to explicitly call out committers/PMC
> privileges. Please review.
>
> Pasting here for convenience
> Committer Privileges
>
>- Committers have write access to the code repository.
>- Committers have an @apache.org email address.
>- Committers can make short-term decisions for the project, approving
>and merging pull requests.
>- Committer Vote is *NOT* considered *binding* thus the vote you cast do
>not have *Veto* on issues that require consensus.
>- Committer's can request changes on Pull Requests but it does not
>constitute Veto, PMC can agree to approve or reject requested changes.
>
> PMC Privileges
>
>- PMC makes the long-term decisions with regard to the project.
>- PMC members have write access to the code repository.
>- PMC members have @apache.org email address.
>- PMC has access to private@ email list
>- PMC has the right to vote for the community-related decisions, PMC
>Votes are *binding*.
>- PMC has the right to propose active users for committership.
>- PMC must vote on any formal release of the project's software product.
>
Could you clarify on this (I don't think you meant "PMC *must* vote")? How
many votes are required by PMCs before the formal release can happen? Is
this considered community-related decision as well, e.g. PMC vetos are
binding?


>
>
> All, I suggest you review the proposal and if there is any concern please
> voice it here before this goes out for voting.
>
>
> On Sun, Oct 28, 2018 at 8:04 AM Carin Meier  wrote:
>
> > I plan to start a vote on the adopting
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > to
> > replace our current document
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > tomorrow
> > (Monday).
> >
> > - Carin
> >
> > On Thu, Oct 25, 2018 at 8:32 AM Carin Meier 
> wrote:
> >
> > > Thanks for publishing the notes and also thanks everyone for providing
> > > valuable feedback and discussion.
> > >
> > > I encourage everyone that has ideas for improvement to the document to
> > > feel free to edit and revise. If you need a login to the wiki, please
> > just
> > > ask.
> > >
> > > Also, while editing, please keep in mind that the intent is to have a
> > vote
> > > on adopting the new
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > > to replace our current document
> > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > > before a vote on separating levels of committer and PPMC as a process.
> > So,
> > > if possible, adopting wording that would work in either outcome of that
> > > vote.
> > >
> > > On the subject of voting, I was thinking of starting a vote on Friday,
> > but
> > > will delay that until the active discussions and revisions are
> complete.
> > >
> > > Best,
> > > Carin
> > >
> > > On Thu, Oct 25, 2018 at 6:39 AM Pedro Larroy <
> > pedro.larroy.li...@gmail.com>
> > > wrote:
> > >
> > >> This is the first hangout that I was able to attend, I liked the
> format
> > >> and
> > >> found them valuable. Thanks for organizing and publishing the notes.
> > >> Looking forward to the next one.
> > >>
> > >> Pedro
> > >>
> > >> On Thu, Oct 25, 2018 at 6:44 AM Steffen Rochel <
> steffenroc...@gmail.com
> > >
> > >> wrote:
> > >>
> > >> > Carin - please see
> > >> >
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/MXNET/Hangout+October+24th+2018+8am+and+5pm+PDT
> > >> > :
> > >> > Discussion about committer proposal:
> > >> >
> > >> >- Proposal default should be to have separation between committer
> > and
> > >> >PPMC election
> > >> >- Criteria are vague, should we add some example persona?
> > >> >- Spell out privileges of committer and PPMC member
> > >> >
> > >> >
> > >> > Note: I update the project proposal to address first bullet.
> > >> >
> > >> > Steffen
> > >> >
> > >> >
> > >> > On Wed, Oct 24, 2018 at 11:29 AM Carin Meier 
> > >> wrote:
> > >> >
> > >> > > A request to whoever is taking notes at the MXNet Hangouts that
> are
> > >> > > occurring today. Could you please recap feedback from the meeting
> in
> > >> > > regards to document revisions here for everyone? I would like to
> > >> attend
> > >> > the
> > >> > > session later today, but may not due to family obligations.
> > >> > >
> > >> > > Thanks!
> > >> > > Carin
> > >> > >
> > >> > > On Tue, Oct 23, 2018 at 2:24 PM Steffen Rochel <
> > >> steffenroc...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Carin - I got feedback on my proposal and made changes. I
> > >> incorporated
> > >> > > > Tianqi's suggesiton that we should strive to nominate
> > committer/PPMC
> > >> > > > candidates from outside ones own organization. It should not be
> > >> > > considered
> > >> >

Re: [DISCUSS] - Revisions to Committer Criteria