Re: users@mxnet

[Sebastian]

I have already proposed this many times in the past and would strongly 
encourage it.


-s

On 15.06.2018 21:56, Sergio Fernández wrote:

Hi,

is there any good reason why the podling doesn't have a users@ mailing list
yet?

Honestly speaking, I'm not a big fan of the other tools the podling is
using. Slack and Web forums a cool tools, and I used them a lot in other
contexts. But when it comes to transparency and community, mailing lists
play a crucial role in the Apache Way.

Users are the most important asset a project can have. Even more than
developers, believe me. So I think it's time to create a users@ mailing
list for to helping MXNet grow its community beyong the core team.

Cheers,

Re: users@mxnet

[Sergio Fernández]

Then, if everybody agree, let's request the mailing list creation to INFRA
;-)

Marco, I wouldn't do that. Typically developers are also subscribed there,
since they may be the most informed people for answering users' questions.
But the topics discussed there may not be of the interest for pure
development purposes. Some discussions will jump from users@ to dev@, but
at a different level. So I wouldn't forward one mailing list to the other.

On Fri, Jun 15, 2018, 21:01 Marco de Abreu
 wrote:

> I think nobody was opposed to it in the past, right?
>
> I'd propose that all emails automatically get copied to dev@ to ensure
> high
> visibility initially. What do you think?
>
> Sebastian  schrieb am Fr., 15. Juni 2018, 20:51:
>
> > I have already proposed this many times in the past and would strongly
> > encourage it.
> >
> > -s
> >
> > On 15.06.2018 21:56, Sergio Fernández wrote:
> > > Hi,
> > >
> > > is there any good reason why the podling doesn't have a users@ mailing
> > list
> > > yet?
> > >
> > > Honestly speaking, I'm not a big fan of the other tools the podling is
> > > using. Slack and Web forums a cool tools, and I used them a lot in
> other
> > > contexts. But when it comes to transparency and community, mailing
> lists
> > > play a crucial role in the Apache Way.
> > >
> > > Users are the most important asset a project can have. Even more than
> > > developers, believe me. So I think it's time to create a users@
> mailing
> > > list for to helping MXNet grow its community beyong the core team.
> > >
> > > Cheers,
> > >
> >
>

Re: users@mxnet

[Sergio Fernández]

Well, I do respect what you discussed in that meetup, if course. But for
those who weren't there, maybe the decision taken what a bit bias.

In Apache we like to say that "if it didn't happen on the mailing list s,
it didn't happen" ;-)

Look like there are different feelings about this. Should I cast a VOTE?


On Fri, Jun 15, 2018, 21:27 Tianqi Chen  wrote:

> I do think we are targeting all the community, but we must also agree that
> the voice of users from the meetup is a representative sample of users'
> demand, and it is important that we respect that.
>
> Tianqi
>
> On Fri, Jun 15, 2018 at 9:25 PM, Sergio Fernández 
> wrote:
>
> > Are we targeting just Seattle as our community? I really hope we are
> > thinking a bit beyond that...
> >
> > On Fri, Jun 15, 2018, 21:22 Tianqi Chen 
> wrote:
> >
> > > I remember last time during the mxnet meetup in Seattle, we did a
> survey,
> > > and most users preferred the current discuss forum. So I would say we
> > stick
> > > with that given the user community prefers that
> > >
> > > Tianqi
> > >
> > > On Fri, Jun 15, 2018 at 9:13 PM, Sergio Fernández 
> > > wrote:
> > >
> > > > Then, if everybody agree, let's request the mailing list creation to
> > > INFRA
> > > > ;-)
> > > >
> > > > Marco, I wouldn't do that. Typically developers are also subscribed
> > > there,
> > > > since they may be the most informed people for answering users'
> > > questions.
> > > > But the topics discussed there may not be of the interest for pure
> > > > development purposes. Some discussions will jump from users@ to dev@
> ,
> > > but
> > > > at a different level. So I wouldn't forward one mailing list to the
> > > other.
> > > >
> > > > On Fri, Jun 15, 2018, 21:01 Marco de Abreu
> > > >  wrote:
> > > >
> > > > > I think nobody was opposed to it in the past, right?
> > > > >
> > > > > I'd propose that all emails automatically get copied to dev@ to
> > ensure
> > > > > high
> > > > > visibility initially. What do you think?
> > > > >
> > > > > Sebastian  schrieb am Fr., 15. Juni 2018, 20:51:
> > > > >
> > > > > > I have already proposed this many times in the past and would
> > > strongly
> > > > > > encourage it.
> > > > > >
> > > > > > -s
> > > > > >
> > > > > > On 15.06.2018 21:56, Sergio Fernández wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > is there any good reason why the podling doesn't have a users@
> > > > mailing
> > > > > > list
> > > > > > > yet?
> > > > > > >
> > > > > > > Honestly speaking, I'm not a big fan of the other tools the
> > podling
> > > > is
> > > > > > > using. Slack and Web forums a cool tools, and I used them a lot
> > in
> > > > > other
> > > > > > > contexts. But when it comes to transparency and community,
> > mailing
> > > > > lists
> > > > > > > play a crucial role in the Apache Way.
> > > > > > >
> > > > > > > Users are the most important asset a project can have. Even
> more
> > > than
> > > > > > > developers, believe me. So I think it's time to create a users@
> > > > > mailing
> > > > > > > list for to helping MXNet grow its community beyong the core
> > team.
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: users@mxnet

[Sergio Fernández]

Are we targeting just Seattle as our community? I really hope we are
thinking a bit beyond that...

On Fri, Jun 15, 2018, 21:22 Tianqi Chen  wrote:

> I remember last time during the mxnet meetup in Seattle, we did a survey,
> and most users preferred the current discuss forum. So I would say we stick
> with that given the user community prefers that
>
> Tianqi
>
> On Fri, Jun 15, 2018 at 9:13 PM, Sergio Fernández 
> wrote:
>
> > Then, if everybody agree, let's request the mailing list creation to
> INFRA
> > ;-)
> >
> > Marco, I wouldn't do that. Typically developers are also subscribed
> there,
> > since they may be the most informed people for answering users'
> questions.
> > But the topics discussed there may not be of the interest for pure
> > development purposes. Some discussions will jump from users@ to dev@,
> but
> > at a different level. So I wouldn't forward one mailing list to the
> other.
> >
> > On Fri, Jun 15, 2018, 21:01 Marco de Abreu
> >  wrote:
> >
> > > I think nobody was opposed to it in the past, right?
> > >
> > > I'd propose that all emails automatically get copied to dev@ to ensure
> > > high
> > > visibility initially. What do you think?
> > >
> > > Sebastian  schrieb am Fr., 15. Juni 2018, 20:51:
> > >
> > > > I have already proposed this many times in the past and would
> strongly
> > > > encourage it.
> > > >
> > > > -s
> > > >
> > > > On 15.06.2018 21:56, Sergio Fernández wrote:
> > > > > Hi,
> > > > >
> > > > > is there any good reason why the podling doesn't have a users@
> > mailing
> > > > list
> > > > > yet?
> > > > >
> > > > > Honestly speaking, I'm not a big fan of the other tools the podling
> > is
> > > > > using. Slack and Web forums a cool tools, and I used them a lot in
> > > other
> > > > > contexts. But when it comes to transparency and community, mailing
> > > lists
> > > > > play a crucial role in the Apache Way.
> > > > >
> > > > > Users are the most important asset a project can have. Even more
> than
> > > > > developers, believe me. So I think it's time to create a users@
> > > mailing
> > > > > list for to helping MXNet grow its community beyong the core team.
> > > > >
> > > > > Cheers,
> > > > >
> > > >
> > >
> >
>

Re: users@mxnet

[Tianqi Chen]

I do think we are targeting all the community, but we must also agree that
the voice of users from the meetup is a representative sample of users'
demand, and it is important that we respect that.

Tianqi

On Fri, Jun 15, 2018 at 9:25 PM, Sergio Fernández  wrote:

> Are we targeting just Seattle as our community? I really hope we are
> thinking a bit beyond that...
>
> On Fri, Jun 15, 2018, 21:22 Tianqi Chen  wrote:
>
> > I remember last time during the mxnet meetup in Seattle, we did a survey,
> > and most users preferred the current discuss forum. So I would say we
> stick
> > with that given the user community prefers that
> >
> > Tianqi
> >
> > On Fri, Jun 15, 2018 at 9:13 PM, Sergio Fernández 
> > wrote:
> >
> > > Then, if everybody agree, let's request the mailing list creation to
> > INFRA
> > > ;-)
> > >
> > > Marco, I wouldn't do that. Typically developers are also subscribed
> > there,
> > > since they may be the most informed people for answering users'
> > questions.
> > > But the topics discussed there may not be of the interest for pure
> > > development purposes. Some discussions will jump from users@ to dev@,
> > but
> > > at a different level. So I wouldn't forward one mailing list to the
> > other.
> > >
> > > On Fri, Jun 15, 2018, 21:01 Marco de Abreu
> > >  wrote:
> > >
> > > > I think nobody was opposed to it in the past, right?
> > > >
> > > > I'd propose that all emails automatically get copied to dev@ to
> ensure
> > > > high
> > > > visibility initially. What do you think?
> > > >
> > > > Sebastian  schrieb am Fr., 15. Juni 2018, 20:51:
> > > >
> > > > > I have already proposed this many times in the past and would
> > strongly
> > > > > encourage it.
> > > > >
> > > > > -s
> > > > >
> > > > > On 15.06.2018 21:56, Sergio Fernández wrote:
> > > > > > Hi,
> > > > > >
> > > > > > is there any good reason why the podling doesn't have a users@
> > > mailing
> > > > > list
> > > > > > yet?
> > > > > >
> > > > > > Honestly speaking, I'm not a big fan of the other tools the
> podling
> > > is
> > > > > > using. Slack and Web forums a cool tools, and I used them a lot
> in
> > > > other
> > > > > > contexts. But when it comes to transparency and community,
> mailing
> > > > lists
> > > > > > play a crucial role in the Apache Way.
> > > > > >
> > > > > > Users are the most important asset a project can have. Even more
> > than
> > > > > > developers, believe me. So I think it's time to create a users@
> > > > mailing
> > > > > > list for to helping MXNet grow its community beyong the core
> team.
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: users@mxnet

[Tianqi Chen]

Then who should represent the users who are using the forums but not the
mail-list? I personally think it is a bit abuse use of the term "Apache
way" to force our mind into the entire community... Maybe I am wrong..

Tianqi

On Fri, Jun 15, 2018 at 9:39 PM, Sergio Fernández  wrote:

> Well, I do respect what you discussed in that meetup, if course. But for
> those who weren't there, maybe the decision taken what a bit bias.
>
> In Apache we like to say that "if it didn't happen on the mailing list s,
> it didn't happen" ;-)
>
> Look like there are different feelings about this. Should I cast a VOTE?
>
>
> On Fri, Jun 15, 2018, 21:27 Tianqi Chen  wrote:
>
> > I do think we are targeting all the community, but we must also agree
> that
> > the voice of users from the meetup is a representative sample of users'
> > demand, and it is important that we respect that.
> >
> > Tianqi
> >
> > On Fri, Jun 15, 2018 at 9:25 PM, Sergio Fernández 
> > wrote:
> >
> > > Are we targeting just Seattle as our community? I really hope we are
> > > thinking a bit beyond that...
> > >
> > > On Fri, Jun 15, 2018, 21:22 Tianqi Chen 
> > wrote:
> > >
> > > > I remember last time during the mxnet meetup in Seattle, we did a
> > survey,
> > > > and most users preferred the current discuss forum. So I would say we
> > > stick
> > > > with that given the user community prefers that
> > > >
> > > > Tianqi
> > > >
> > > > On Fri, Jun 15, 2018 at 9:13 PM, Sergio Fernández  >
> > > > wrote:
> > > >
> > > > > Then, if everybody agree, let's request the mailing list creation
> to
> > > > INFRA
> > > > > ;-)
> > > > >
> > > > > Marco, I wouldn't do that. Typically developers are also subscribed
> > > > there,
> > > > > since they may be the most informed people for answering users'
> > > > questions.
> > > > > But the topics discussed there may not be of the interest for pure
> > > > > development purposes. Some discussions will jump from users@ to
> dev@
> > ,
> > > > but
> > > > > at a different level. So I wouldn't forward one mailing list to the
> > > > other.
> > > > >
> > > > > On Fri, Jun 15, 2018, 21:01 Marco de Abreu
> > > > >  wrote:
> > > > >
> > > > > > I think nobody was opposed to it in the past, right?
> > > > > >
> > > > > > I'd propose that all emails automatically get copied to dev@ to
> > > ensure
> > > > > > high
> > > > > > visibility initially. What do you think?
> > > > > >
> > > > > > Sebastian  schrieb am Fr., 15. Juni 2018, 20:51:
> > > > > >
> > > > > > > I have already proposed this many times in the past and would
> > > > strongly
> > > > > > > encourage it.
> > > > > > >
> > > > > > > -s
> > > > > > >
> > > > > > > On 15.06.2018 21:56, Sergio Fernández wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > is there any good reason why the podling doesn't have a
> users@
> > > > > mailing
> > > > > > > list
> > > > > > > > yet?
> > > > > > > >
> > > > > > > > Honestly speaking, I'm not a big fan of the other tools the
> > > podling
> > > > > is
> > > > > > > > using. Slack and Web forums a cool tools, and I used them a
> lot
> > > in
> > > > > > other
> > > > > > > > contexts. But when it comes to transparency and community,
> > > mailing
> > > > > > lists
> > > > > > > > play a crucial role in the Apache Way.
> > > > > > > >
> > > > > > > > Users are the most important asset a project can have. Even
> > more
> > > > than
> > > > > > > > developers, believe me. So I think it's time to create a
> users@
> > > > > > mailing
> > > > > > > > list for to helping MXNet grow its community beyong the core
> > > team.
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: users@mxnet

[Tianqi Chen]

I don't want to argue here, as "Apache way" also says VOTE should not be a
way to enforce our opinion, and consensus need to be reached through
discussion

Thanks!

Tianqi

On Fri, Jun 15, 2018 at 9:41 PM, Tianqi Chen 
wrote:

> Then who should represent the users who are using the forums but not the
> mail-list? I personally think it is a bit abuse use of the term "Apache
> way" to force our mind into the entire community... Maybe I am wrong..
>
> Tianqi
>
> On Fri, Jun 15, 2018 at 9:39 PM, Sergio Fernández 
> wrote:
>
>> Well, I do respect what you discussed in that meetup, if course. But for
>> those who weren't there, maybe the decision taken what a bit bias.
>>
>> In Apache we like to say that "if it didn't happen on the mailing list s,
>> it didn't happen" ;-)
>>
>> Look like there are different feelings about this. Should I cast a VOTE?
>>
>>
>> On Fri, Jun 15, 2018, 21:27 Tianqi Chen  wrote:
>>
>> > I do think we are targeting all the community, but we must also agree
>> that
>> > the voice of users from the meetup is a representative sample of users'
>> > demand, and it is important that we respect that.
>> >
>> > Tianqi
>> >
>> > On Fri, Jun 15, 2018 at 9:25 PM, Sergio Fernández 
>> > wrote:
>> >
>> > > Are we targeting just Seattle as our community? I really hope we are
>> > > thinking a bit beyond that...
>> > >
>> > > On Fri, Jun 15, 2018, 21:22 Tianqi Chen 
>> > wrote:
>> > >
>> > > > I remember last time during the mxnet meetup in Seattle, we did a
>> > survey,
>> > > > and most users preferred the current discuss forum. So I would say
>> we
>> > > stick
>> > > > with that given the user community prefers that
>> > > >
>> > > > Tianqi
>> > > >
>> > > > On Fri, Jun 15, 2018 at 9:13 PM, Sergio Fernández <
>> wik...@apache.org>
>> > > > wrote:
>> > > >
>> > > > > Then, if everybody agree, let's request the mailing list creation
>> to
>> > > > INFRA
>> > > > > ;-)
>> > > > >
>> > > > > Marco, I wouldn't do that. Typically developers are also
>> subscribed
>> > > > there,
>> > > > > since they may be the most informed people for answering users'
>> > > > questions.
>> > > > > But the topics discussed there may not be of the interest for pure
>> > > > > development purposes. Some discussions will jump from users@ to
>> dev@
>> > ,
>> > > > but
>> > > > > at a different level. So I wouldn't forward one mailing list to
>> the
>> > > > other.
>> > > > >
>> > > > > On Fri, Jun 15, 2018, 21:01 Marco de Abreu
>> > > > >  wrote:
>> > > > >
>> > > > > > I think nobody was opposed to it in the past, right?
>> > > > > >
>> > > > > > I'd propose that all emails automatically get copied to dev@ to
>> > > ensure
>> > > > > > high
>> > > > > > visibility initially. What do you think?
>> > > > > >
>> > > > > > Sebastian  schrieb am Fr., 15. Juni 2018,
>> 20:51:
>> > > > > >
>> > > > > > > I have already proposed this many times in the past and would
>> > > > strongly
>> > > > > > > encourage it.
>> > > > > > >
>> > > > > > > -s
>> > > > > > >
>> > > > > > > On 15.06.2018 21:56, Sergio Fernández wrote:
>> > > > > > > > Hi,
>> > > > > > > >
>> > > > > > > > is there any good reason why the podling doesn't have a
>> users@
>> > > > > mailing
>> > > > > > > list
>> > > > > > > > yet?
>> > > > > > > >
>> > > > > > > > Honestly speaking, I'm not a big fan of the other tools the
>> > > podling
>> > > > > is
>> > > > > > > > using. Slack and Web forums a cool tools, and I used them a
>> lot
>> > > in
>> > > > > > other
>> > > > > > > > contexts. But when it comes to transparency and community,
>> > > mailing
>> > > > > > lists
>> > > > > > > > play a crucial role in the Apache Way.
>> > > > > > > >
>> > > > > > > > Users are the most important asset a project can have. Even
>> > more
>> > > > than
>> > > > > > > > developers, believe me. So I think it's time to create a
>> users@
>> > > > > > mailing
>> > > > > > > > list for to helping MXNet grow its community beyong the core
>> > > team.
>> > > > > > > >
>> > > > > > > > Cheers,
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: Request for Sign up

[Aaron Markham]

Hi,
Have you checked out this page?
https://mxnet.incubator.apache.org/community/contribute.html

The dev comm section has info on how to subscribe to the mail list.

I think Steffen already added you to slack.

On Fri, Jun 15, 2018, 16:33 Kalyanee Chendke  wrote:

> Hello,
>
> Bumping this up. I would like to request to sign up.
>
> -Kalyanee
>
> Kalyanee
>
> On Thu, Jun 7, 2018 at 11:27 AM, Kalyanee Chendke 
> wrote:
>
> > Hey!
> >
> > I would like to request for sign up to the MXNet Apache Mailing list &
> > also to the MXNet Slack Channel.
> >
> > Kalyanee
> >
>

Re: users@mxnet

[Marco de Abreu]

I think nobody was opposed to it in the past, right?

I'd propose that all emails automatically get copied to dev@ to ensure high
visibility initially. What do you think?

Sebastian  schrieb am Fr., 15. Juni 2018, 20:51:

> I have already proposed this many times in the past and would strongly
> encourage it.
>
> -s
>
> On 15.06.2018 21:56, Sergio Fernández wrote:
> > Hi,
> >
> > is there any good reason why the podling doesn't have a users@ mailing
> list
> > yet?
> >
> > Honestly speaking, I'm not a big fan of the other tools the podling is
> > using. Slack and Web forums a cool tools, and I used them a lot in other
> > contexts. But when it comes to transparency and community, mailing lists
> > play a crucial role in the Apache Way.
> >
> > Users are the most important asset a project can have. Even more than
> > developers, believe me. So I think it's time to create a users@ mailing
> > list for to helping MXNet grow its community beyong the core team.
> >
> > Cheers,
> >
>

Re: Request for Sign up

[Kalyanee Chendke]

Hello,

Bumping this up. I would like to request to sign up.

-Kalyanee

Kalyanee

On Thu, Jun 7, 2018 at 11:27 AM, Kalyanee Chendke 
wrote:

> Hey!
>
> I would like to request for sign up to the MXNet Apache Mailing list &
> also to the MXNet Slack Channel.
>
> Kalyanee
>

Re: users@mxnet

[Tianqi Chen]

I remember last time during the mxnet meetup in Seattle, we did a survey,
and most users preferred the current discuss forum. So I would say we stick
with that given the user community prefers that

Tianqi

On Fri, Jun 15, 2018 at 9:13 PM, Sergio Fernández  wrote:

> Then, if everybody agree, let's request the mailing list creation to INFRA
> ;-)
>
> Marco, I wouldn't do that. Typically developers are also subscribed there,
> since they may be the most informed people for answering users' questions.
> But the topics discussed there may not be of the interest for pure
> development purposes. Some discussions will jump from users@ to dev@, but
> at a different level. So I wouldn't forward one mailing list to the other.
>
> On Fri, Jun 15, 2018, 21:01 Marco de Abreu
>  wrote:
>
> > I think nobody was opposed to it in the past, right?
> >
> > I'd propose that all emails automatically get copied to dev@ to ensure
> > high
> > visibility initially. What do you think?
> >
> > Sebastian  schrieb am Fr., 15. Juni 2018, 20:51:
> >
> > > I have already proposed this many times in the past and would strongly
> > > encourage it.
> > >
> > > -s
> > >
> > > On 15.06.2018 21:56, Sergio Fernández wrote:
> > > > Hi,
> > > >
> > > > is there any good reason why the podling doesn't have a users@
> mailing
> > > list
> > > > yet?
> > > >
> > > > Honestly speaking, I'm not a big fan of the other tools the podling
> is
> > > > using. Slack and Web forums a cool tools, and I used them a lot in
> > other
> > > > contexts. But when it comes to transparency and community, mailing
> > lists
> > > > play a crucial role in the Apache Way.
> > > >
> > > > Users are the most important asset a project can have. Even more than
> > > > developers, believe me. So I think it's time to create a users@
> > mailing
> > > > list for to helping MXNet grow its community beyong the core team.
> > > >
> > > > Cheers,
> > > >
> > >
> >
>

Re: users@mxnet

[Tianqi Chen]

So unless there is a strong evidence that our community users prefers the
mail-list, I would recommend we keep the current way

Tianqi

On Fri, Jun 15, 2018 at 9:25 PM, Sergio Fernández  wrote:

> Are we targeting just Seattle as our community? I really hope we are
> thinking a bit beyond that...
>
> On Fri, Jun 15, 2018, 21:22 Tianqi Chen  wrote:
>
> > I remember last time during the mxnet meetup in Seattle, we did a survey,
> > and most users preferred the current discuss forum. So I would say we
> stick
> > with that given the user community prefers that
> >
> > Tianqi
> >
> > On Fri, Jun 15, 2018 at 9:13 PM, Sergio Fernández 
> > wrote:
> >
> > > Then, if everybody agree, let's request the mailing list creation to
> > INFRA
> > > ;-)
> > >
> > > Marco, I wouldn't do that. Typically developers are also subscribed
> > there,
> > > since they may be the most informed people for answering users'
> > questions.
> > > But the topics discussed there may not be of the interest for pure
> > > development purposes. Some discussions will jump from users@ to dev@,
> > but
> > > at a different level. So I wouldn't forward one mailing list to the
> > other.
> > >
> > > On Fri, Jun 15, 2018, 21:01 Marco de Abreu
> > >  wrote:
> > >
> > > > I think nobody was opposed to it in the past, right?
> > > >
> > > > I'd propose that all emails automatically get copied to dev@ to
> ensure
> > > > high
> > > > visibility initially. What do you think?
> > > >
> > > > Sebastian  schrieb am Fr., 15. Juni 2018, 20:51:
> > > >
> > > > > I have already proposed this many times in the past and would
> > strongly
> > > > > encourage it.
> > > > >
> > > > > -s
> > > > >
> > > > > On 15.06.2018 21:56, Sergio Fernández wrote:
> > > > > > Hi,
> > > > > >
> > > > > > is there any good reason why the podling doesn't have a users@
> > > mailing
> > > > > list
> > > > > > yet?
> > > > > >
> > > > > > Honestly speaking, I'm not a big fan of the other tools the
> podling
> > > is
> > > > > > using. Slack and Web forums a cool tools, and I used them a lot
> in
> > > > other
> > > > > > contexts. But when it comes to transparency and community,
> mailing
> > > > lists
> > > > > > play a crucial role in the Apache Way.
> > > > > >
> > > > > > Users are the most important asset a project can have. Even more
> > than
> > > > > > developers, believe me. So I think it's time to create a users@
> > > > mailing
> > > > > > list for to helping MXNet grow its community beyong the core
> team.
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > >
> > > >
> > >
> >
>

users@mxnet

[Sergio Fernández]

Hi,

is there any good reason why the podling doesn't have a users@ mailing list
yet?

Honestly speaking, I'm not a big fan of the other tools the podling is
using. Slack and Web forums a cool tools, and I used them a lot in other
contexts. But when it comes to transparency and community, mailing lists
play a crucial role in the Apache Way.

Users are the most important asset a project can have. Even more than
developers, believe me. So I think it's time to create a users@ mailing
list for to helping MXNet grow its community beyong the core team.

Cheers,

Re: Clojure Package

[Carin Meier]

Kovas Boguta https://twitter.com/kovasb, from the Clojure/AI community,
graciously took some time to review the PR for the clojure package.

He had some insightful feedback and high level questions that I thought
might be of interest to the larger dev mailing list.

https://github.com/apache/incubator-mxnet/pull/11205

Feel free to join in on the discussion here or on the PR.

- Carin

On Mon, Jun 11, 2018 at 6:49 PM, Carin Meier  wrote:

> I'm fine with whatever process works best and what makes everyone the most
> comfortable.
>
> I've completed one of the requests for code coverage and integrated the
> cloverage, (https://github.com/cloverage/cloverage), plugin in the PR
> branch. I've published the results to the confluence page to help with
> transparency and give everyone a better idea where the level of testing is
> currently.
> https://cwiki.apache.org/confluence/display/MXNET/
> Clojure+Package+Contribution+Needs
>
>
>
> On Mon, Jun 11, 2018 at 6:24 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com> wrote:
>
>> Exactly, that's what I'm proposing. Having the migration in multiple
>> separate PRs which are done in sequence. This would mean that the initial
>> PRs might not be tested.
>> We could make the factors you mentioned acceptance criteria to be moved
>> out
>> of contrib.
>>
>> -Marco
>>
>> On Mon, Jun 11, 2018 at 3:17 PM Naveen Swamy  wrote:
>>
>> > I did not suggest to do it at once. I am not comfortable to merge code
>> > without good tests, documentation and examples that is not to say
>> Clojure
>> > codebase does not have that.
>> > All that you are saying can happen in separate PRs if you want to break
>> it
>> > up.
>> >
>> >
>> > On Tue, Jun 12, 2018 at 12:07 AM, Marco de Abreu <
>> > marco.g.ab...@googlemail.com> wrote:
>> >
>> > > The problem I see here is that the migration will have different type
>> of
>> > > challenges which should be handled isolated. Trying to solve them all
>> at
>> > > once will make it very lengthy and also hard to review. Considering
>> Carin
>> > > and her team this is doing this on a voluntary base, I'd like to keep
>> the
>> > > number of hoops to jump through per stage as small as possible and
>> rather
>> > > split it up into multiple efforts.
>> > >
>> > > If we would do everything at once, we'd have to involve a lot of
>> people
>> > and
>> > > it would be hard to review. We'd need at least two or three reviewers
>> > > involved in that process: You (or another committer familiar with
>> Scala
>> > to
>> > > review the Scala part), Yi Zhi (general reviewer) and me (CI
>> > integration).
>> > > It would probably require even more committers for other stuff that
>> comes
>> > > up. It would rather be better to keep the parts that have to be
>> touched
>> > as
>> > > isolated and few as possible.
>> > > For example, after the code has been approved and merged in general, I
>> > can
>> > > assist with the CI integration. This would not require oversight from
>> > other
>> > > committers, so they'd be free. After that, we'd need somebody familiar
>> > with
>> > > the release process (probably Naveen) and I'd be free after that.
>> Then we
>> > > need general improvements which would also involve other people again.
>> > > Trying to squeeze everything into a single stage is going to make it
>> very
>> > > hard in my opinion.
>> > >
>> > >
>> > > -Marco
>> > >
>> > > On Mon, Jun 11, 2018 at 2:56 PM Naveen Swamy 
>> wrote:
>> > >
>> > > > I disagree with your approach, We should bring features iteratively
>> > well
>> > > > tested and well documented. MXNet already has many different
>> language
>> > > > bindings which has quite a bit of tech-debt, I don't want just to
>> add
>> > > more
>> > > > tech-debt to the code base with new language bindings as well.
>> > > >
>> > > > On Mon, Jun 11, 2018 at 11:17 PM, Marco de Abreu <
>> > > > marco.g.ab...@googlemail.com> wrote:
>> > > >
>> > > > > I think we should try to separate this migration into multiple
>> > stages:
>> > > > > 1. Move into contrib
>> > > > > 2. Migrate release pipeline
>> > > > > 3. Migrate tests
>> > > > > 4. Improvements
>> > > > > 5. Mark as stable and announce Julia officially
>> > > > >
>> > > > > I know how much effort Carin and the other maintainers are putting
>> > into
>> > > > > that project and thus I'd like to make the migration as easy as
>> > > possible.
>> > > > > If we try to cover release, test and improvements from Day 1,
>> we're
>> > > going
>> > > > > to make the entire migration a very hard and lengthy process.
>> > > Considering
>> > > > > the project already has its own CI and maintains a high code
>> quality,
>> > > I'm
>> > > > > confident that some time without CI would be fine. We should make
>> > this
>> > > > > iteratively. The first big goal would really be to have the
>> project
>> > in
>> > > > our
>> > > > > repository - everything else can be followed up later on.
>> > > > >
>> > > > > -Marco
>> > > > >
>> > > > >
>> > > > > On Sun, Jun 10, 2018 at 8:08 

Re: About Becoming a Committer

[Tianqi Chen]

First of all, Apache allows each community to define its standard of
comittership -- which I think is super valuable as different projects have
different backgrounds and challenges. Having such flexibility instead of
enforcing a global standard is one of the reasons why many Apache projects
succeed. Here is my reasoning on the standard.

First of all, all contributions are valuable, and we evaluate them when
considering committer nominations and evaluate them in an unbiased way.
On the other hand, it is hard to create a standard of "equality" of
contributions. Hen's suggestion of code being committed is a good proposal,
but never-the-less biased against contributions that bring in drastically
new design (we can call these type of contributors "pioneers"). The reason
behind this is clear -- it is arguably true that contributions of new
proposals are easier to bring in mistakes, and take a longer time to pass
code reviews (thus costs more effort of fellow committers). "pioneers" get
shot down more easily -- which is not what we want to see. Bring it to
MXNet and the playground we are facing. We are on a super competitive
field, with major tech giants in the play. All the players in the field are
trying out drastically new ideas, and it is even more in our case to not
have such bias.

So it is indeed important to evaluate it on the basis of contribution,
"quality" is just one word that we choose, and we put trust on the
committers when evaluating them. While it is indeed hard to define such
standard, we are trying our best to make fair evaluations.



On Fri, Jun 15, 2018 at 12:00 AM, Hen  wrote:

> On the 'Becoming+a+Committer' guidelines, I dislike this phrase:
>
> "When it comes to code contributions, quality is more important than
> quantity"
>
> There is only one 'quality' measurement, and that is "was the code merged".
> If someone makes 10 different contributions and they were all horrible and
> never merged (or the merger had to write a ton of fixes/tests/additions)
> then yes, that's a pretty bad sign.
>
> If the code was merged; I don't care if it's stunning code or an inspired
> design. It was merged. This isn't a technical promotion process, this is
> about whether the individual has shown the commitment to be extended the
> trust to manage commits.
>
> So; -1 to quality being more important than quantity. It's not.
>
> Hen
>
>
>
> On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha  wrote:
>
> > Hi,
> >
> > There have been a couple of offline inquiries from contributors about
> > becoming a committer. From those inquiries, it seems that there’s
> confusion
> > in our community about how to become a committer, so I’d like to take
> this
> > opportunity to clarify.
> >
> > The guideline about becoming a committer can be found at
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer.
> > The
> > gist of the guideline is that, like any other Apache project, MXNet
> > committers are invited by existing committers based on merit. The
> existing
> > committers look for sustained, high quality contribution and community
> > involvement among project contributors. When a candidate is spotted, this
> > contributor will be nominated and voted among PMC members, and if all
> goes
> > well, this contributor will receive an invitation to join as a committer
> > and PMC member.
> >
> > Note that such discussion and decision happens in private among existing
> > PMC members and mentors through consensus, and information regarding what
> > happened in this process will always remain private, so as to rid the
> > influence of different interest groups. PMC members will not ask
> > contributors for committer application, nor will they accept one. Except
> > the aforementioned PMC members consensus process, any other process by
> any
> > organization under any circumstances will not be recognized.
> >
> > I hope that you find the above clarification helpful. If you have further
> > question on this topic feel free to ask.
> >
> > Sheng
> >
>

Re: Reverting pull request

[Tianqi Chen]

+1   We would be stuck at local minimums if we just keep reverting the PR
that brings improvements in the long term

Tianqi

On Fri, Jun 15, 2018 at 2:15 PM, Mu Li  wrote:

> Why reverting instead of fixing the bugs? Static memory aims to reduce
> memory allocation, it's a key feature to bridge the perf gap between gluon
> and symbol.
>
> On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
> > Hello,
> >
> > I'm reverting https://github.com/apache/incubator-mxnet/pull/10817 as of
> > https://github.com/apache/incubator-mxnet/pull/11311 due to regressions
> > described in https://github.com/apache/incubator-mxnet/issues/11171 and
> > https://github.com/apache/incubator-mxnet/pull/10817.
> >
> > The pull request has been self-merged without proper review and
> introduced
> > regressions. Committers should act as role models in this project and
> > adhere to software engineer best practices.
> >
> > Best regards,
> > Marco
> >
>

Re: Reverting pull request

[Marco de Abreu]

We revert a PR because it should not have been merged in the first place.
So far, I have been ignoring the fact that our committers are constantly
breaking our own rules (which we expect contributors to follow). But since
this caused an impact twice (1.2 breaking change about model import/export
as well as this regression), I'm now being more strict and enforcing them.

I could've also made a script that prevents any PR from being self-merged,
but I thought our committers are responsible enough to follow our own rules
without systems actually enforcing them. I won't waste my time working on
that script, but from now on I will revert every single PR (except
emergency cases) that has been self-merged without approval.

-Marco

On Fri, Jun 15, 2018 at 2:15 PM Mu Li  wrote:

> Why reverting instead of fixing the bugs? Static memory aims to reduce
> memory allocation, it's a key feature to bridge the perf gap between gluon
> and symbol.
>
> On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
> > Hello,
> >
> > I'm reverting https://github.com/apache/incubator-mxnet/pull/10817 as of
> > https://github.com/apache/incubator-mxnet/pull/11311 due to regressions
> > described in https://github.com/apache/incubator-mxnet/issues/11171 and
> > https://github.com/apache/incubator-mxnet/pull/10817.
> >
> > The pull request has been self-merged without proper review and
> introduced
> > regressions. Committers should act as role models in this project and
> > adhere to software engineer best practices.
> >
> > Best regards,
> > Marco
> >
>

Re: Reverting pull request

[Zheng, Da]

+1 The PR has been merged a while ago, so it has been tested by many people.
Other people's work now depends on this PR. Reverting it at this point can 
cause a lot of problems for many other people.

Best,
Da

On 6/15/18, 2:18 PM, "workc...@gmail.com on behalf of Tianqi Chen" 
 wrote:

+1   We would be stuck at local minimums if we just keep reverting the PR
that brings improvements in the long term

Tianqi

On Fri, Jun 15, 2018 at 2:15 PM, Mu Li  wrote:

> Why reverting instead of fixing the bugs? Static memory aims to reduce
> memory allocation, it's a key feature to bridge the perf gap between gluon
> and symbol.
>
> On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
> > Hello,
> >
> > I'm reverting https://github.com/apache/incubator-mxnet/pull/10817 as of
> > https://github.com/apache/incubator-mxnet/pull/11311 due to regressions
> > described in https://github.com/apache/incubator-mxnet/issues/11171 and
> > https://github.com/apache/incubator-mxnet/pull/10817.
> >
> > The pull request has been self-merged without proper review and
> introduced
> > regressions. Committers should act as role models in this project and
> > adhere to software engineer best practices.
> >
> > Best regards,
> > Marco
> >
>

Re: MXNet issues labeling

[Marco de Abreu]

Mentors, do you know if it is possible to get a bot account with these
restricted permissions? I know that previous requests have been declined by
Apache Infra. Shall we try it again or how shall we continue moving forward?

-Marco

On Fri, Jun 15, 2018 at 2:09 PM Qing Lan  wrote:

> Hi All,
> I would like to quote this:
> ```
> Cathy:
> I am working on this label bot to automate/simplify this labeling issue
> process and send weekly report to maintainers. Design proposal is on cwiki:
>
> https://cwiki.apache.org/confluence/display/MXNET/Deep+Learning+Based+GitHub+Label+Bot
>
> Please feel free to let me know if you have
> suggestions/requirements/expectations.
>
> Thanks,
> Cathy
> ```
> Currently Cathy has done the design for labelling the issues and I believe
> that will help our community to track more issues quickly.
> Since we received a lot of +1s from this list last time, I would like to
> ask for a Label adding/removing permission for the bot that Cathy designed.
> Can we do something like this for a GitHub account?
>
> Thanks,
> Qing
>
> On 5/22/18, 9:56 AM, "Roshani Nagmote"  wrote:
>
> Sorry for incomplete email. Sent it too fast.
> Thanks for all the comments. Aaron guessed it right. We can treat it
> as a
> multi-label classification problem. :)
> We are currently working on the design document, will share it on dev
> list
> once it is more concrete.
>
> @Marco, seems like a good idea too but as you said, it will still
> involve
> manual labeling. We can do this as a temporary solution but need a
> long-term solution.
> @Hao, will explore that option too! Thanks!
>
> Thanks,
> Roshani
>
>
> On Tue, May 22, 2018 at 9:52 AM, Roshani Nagmote <
> roshaninagmo...@gmail.com>
> wrote:
>
> > Thanks for all the comments. Aaron guessed it right. We can treat it
> as a
> > multi-label classification problem. :)
> > We are currently working on the design document, will share it on
> dev list
> > once it is more concrete.
> >
> > @Marco, seems like a good idea too but as you said, it will still
> involve
> > manual labeling. We can do this as a temporary solution but need a
> more
> > @Hao, will explore that option too! Thanks!
> >
> > Thanks,
> > Roshani
> >
> > On Mon, May 21, 2018 at 5:42 PM, Jin, Hao  wrote:
> >
> >> Definitely a good idea. I think maybe we can also try out the new
> gluon
> >> NLP toolkit on this task?
> >>
> >> On 5/21/18, 5:24 PM, "Anirudh"  wrote:
> >>
> >> Yes, I guessed that :). Was looking for more details.
> >>
> >> On Mon, May 21, 2018 at 5:03 PM, Aaron Markham <
> >> aaron.s.mark...@gmail.com>
> >> wrote:
> >>
> >> > AI obviously.
> >> >
> >> > On Mon, May 21, 2018 at 5:01 PM, Anirudh <
> anirudh2...@gmail.com>
> >> wrote:
> >> >
> >> > > Hi Roshani,
> >> > >
> >> > > Good suggestion! How will the bot decide what labels to add
> ?
> >> > >
> >> > > Anirudh
> >> > >
> >> > > On Mon, May 21, 2018 at 4:39 PM, Naveen Swamy <
> mnnav...@gmail.com
> >> >
> >> > wrote:
> >> > >
> >> > > > +1 for the proposal to triage issues, I think committers
> should
> >> also do
> >> > > > this exercise to understand the customer pain.
> >> > > >
> >> > > > I am also inclined to use a bot account like how
> Tensorflow and
> >> other
> >> > > repos
> >> > > > do it, https://github.com/googlebot.
> >> > > >
> https://github.com/tensorflow/tensorflow/pull/19445#event-16
> >> 38027271
> >> > -->
> >> > > > This is auto-tagged by the bot, it would be cool if we
> could do
> >> that as
> >> > > > well.
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Mon, May 21, 2018 at 4:25 PM, sandeep krishnamurthy <
> >> > > > sandeep.krishn...@gmail.com> wrote:
> >> > > >
> >> > > > > Thanks,
> >> > > > >
> >> > > > > Roshani for starting this thread.
> >> > > > >
> >> > > > > Yes, I think labeling the issues will help a lot in
> driving
> >> the
> >> > > attention
> >> > > > > of contributors to specific areas and make it easy for
> new
> >> > contributors
> >> > > > to
> >> > > > > search and pick their contribution.
> >> > > > >
> >> > > > > I agree manually doing it all the time is not scalable
> and
> >> efficient.
> >> > > > Your
> >> > > > > proposal on bot script to auto-label, similar to the
> working
> >> of
> >> > Jenkins
> >> > > > bot
> >> > > > > to re-test, re-build actions, will be very useful and
> >> effective.
> >> > > Hence, I
> >> > > > > am more inclined to your *option 1* to have a bot
> account to
> >> add
> 

Re: Reverting pull request

[Marco de Abreu]

If it causes issues, I'd like to invite everybody to direct their requests
to Eric since he merged the PR prematurely. The committer who merges a PR
is responsible and can be held liable for any negative impact being the
result of their action [1].

[1]: https://www.apache.org/dev/committers.html#committer-responsibilities

On Fri, Jun 15, 2018 at 2:23 PM Zheng, Da  wrote:

> +1 The PR has been merged a while ago, so it has been tested by many
> people.
> Other people's work now depends on this PR. Reverting it at this point can
> cause a lot of problems for many other people.
>
> Best,
> Da
>
> On 6/15/18, 2:18 PM, "workc...@gmail.com on behalf of Tianqi Chen" <
> workc...@gmail.com on behalf of tqc...@cs.washington.edu> wrote:
>
> +1   We would be stuck at local minimums if we just keep reverting the
> PR
> that brings improvements in the long term
>
> Tianqi
>
> On Fri, Jun 15, 2018 at 2:15 PM, Mu Li  wrote:
>
> > Why reverting instead of fixing the bugs? Static memory aims to
> reduce
> > memory allocation, it's a key feature to bridge the perf gap between
> gluon
> > and symbol.
> >
> > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > marco.g.ab...@googlemail.com.invalid> wrote:
> >
> > > Hello,
> > >
> > > I'm reverting https://github.com/apache/incubator-mxnet/pull/10817
> as of
> > > https://github.com/apache/incubator-mxnet/pull/11311 due to
> regressions
> > > described in
> https://github.com/apache/incubator-mxnet/issues/11171 and
> > > https://github.com/apache/incubator-mxnet/pull/10817.
> > >
> > > The pull request has been self-merged without proper review and
> > introduced
> > > regressions. Committers should act as role models in this project
> and
> > > adhere to software engineer best practices.
> > >
> > > Best regards,
> > > Marco
> > >
> >
>
>
>

Re: Reverting pull request

[Tianqi Chen]

He already sends in the fix.
I agree with your point about not being self-merging, but a proper way
would bring this issue up friendly and move forward with a better fix. We
should not shoot every contributor for a bug they introduced due to new
features as long as they take responsibility to fix it.

Tianqi

On Fri, Jun 15, 2018 at 2:27 PM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> If it causes issues, I'd like to invite everybody to direct their requests
> to Eric since he merged the PR prematurely. The committer who merges a PR
> is responsible and can be held liable for any negative impact being the
> result of their action [1].
>
> [1]: https://www.apache.org/dev/committers.html#committer-responsibilities
>
> On Fri, Jun 15, 2018 at 2:23 PM Zheng, Da 
> wrote:
>
> > +1 The PR has been merged a while ago, so it has been tested by many
> > people.
> > Other people's work now depends on this PR. Reverting it at this point
> can
> > cause a lot of problems for many other people.
> >
> > Best,
> > Da
> >
> > On 6/15/18, 2:18 PM, "workc...@gmail.com on behalf of Tianqi Chen" <
> > workc...@gmail.com on behalf of tqc...@cs.washington.edu> wrote:
> >
> > +1   We would be stuck at local minimums if we just keep reverting
> the
> > PR
> > that brings improvements in the long term
> >
> > Tianqi
> >
> > On Fri, Jun 15, 2018 at 2:15 PM, Mu Li  wrote:
> >
> > > Why reverting instead of fixing the bugs? Static memory aims to
> > reduce
> > > memory allocation, it's a key feature to bridge the perf gap
> between
> > gluon
> > > and symbol.
> > >
> > > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > > marco.g.ab...@googlemail.com.invalid> wrote:
> > >
> > > > Hello,
> > > >
> > > > I'm reverting https://github.com/apache/
> incubator-mxnet/pull/10817
> > as of
> > > > https://github.com/apache/incubator-mxnet/pull/11311 due to
> > regressions
> > > > described in
> > https://github.com/apache/incubator-mxnet/issues/11171 and
> > > > https://github.com/apache/incubator-mxnet/pull/10817.
> > > >
> > > > The pull request has been self-merged without proper review and
> > > introduced
> > > > regressions. Committers should act as role models in this project
> > and
> > > > adhere to software engineer best practices.
> > > >
> > > > Best regards,
> > > > Marco
> > > >
> > >
> >
> >
> >
>

Re: Reverting pull request

[Thomas DELTEIL]

Copying a comment I made on a flaky test introduced by this PR:
https://github.com/apache/incubator-mxnet/issues/11171

"

@piiswrong  you introduced this test in this
commit

[WIP] Do Not Merge. Static memory allocation for cached_op (#10817
) 2dbd143


and it seems to be flaky. I have seen it failing a few times in recent
builds. Can you take a look? e.g
http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/incubator-mxnet/detail/master/1002/pipeline/

Given all the talk about quality contributions going on the dev mailing
list, I am a little unsettled by the fact this PR went undocumented (no
design docs or explanation in the PR), unreviewed (1 question ignored), the
optimization wasn't tested or benchmarked (it was actually making things
slower), and the code was self-merged.

Should we enforce that each PR , especially the ones that introduce a
significant number of changes be properly documented and reviewed before
merging?

"

My main gripe is that there is literally no description of what the PR is
achieving, no design docs to refer to.

I spent time benchmarking the different optimization because I thought I
did something wrong when I found that it was slower with the optimization.
I would have hoped that a significant change like that would have at least
been benchmarked.

In French we say "Il ne faut pas confondre vitesse et precipitation" which
loosely translates to "Haste makes waste".

I would advocate to take the time to document PRs properly, benchmark and
thoroughly test significant changes. Because down the line, other users end
up losing so much more time trying to figure out what is happening when
things go wrong (like here).

Thanks,


Thomas

2018-06-15 14:27 GMT-07:00 Marco de Abreu <
marco.g.ab...@googlemail.com.invalid>:

> If it causes issues, I'd like to invite everybody to direct their requests
> to Eric since he merged the PR prematurely. The committer who merges a PR
> is responsible and can be held liable for any negative impact being the
> result of their action [1].
>
> [1]: https://www.apache.org/dev/committers.html#committer-responsibilities
>
> On Fri, Jun 15, 2018 at 2:23 PM Zheng, Da 
> wrote:
>
> > +1 The PR has been merged a while ago, so it has been tested by many
> > people.
> > Other people's work now depends on this PR. Reverting it at this point
> can
> > cause a lot of problems for many other people.
> >
> > Best,
> > Da
> >
> > On 6/15/18, 2:18 PM, "workc...@gmail.com on behalf of Tianqi Chen" <
> > workc...@gmail.com on behalf of tqc...@cs.washington.edu> wrote:
> >
> > +1   We would be stuck at local minimums if we just keep reverting
> the
> > PR
> > that brings improvements in the long term
> >
> > Tianqi
> >
> > On Fri, Jun 15, 2018 at 2:15 PM, Mu Li  wrote:
> >
> > > Why reverting instead of fixing the bugs? Static memory aims to
> > reduce
> > > memory allocation, it's a key feature to bridge the perf gap
> between
> > gluon
> > > and symbol.
> > >
> > > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > > marco.g.ab...@googlemail.com.invalid> wrote:
> > >
> > > > Hello,
> > > >
> > > > I'm reverting https://github.com/apache/
> incubator-mxnet/pull/10817
> > as of
> > > > https://github.com/apache/incubator-mxnet/pull/11311 due to
> > regressions
> > > > described in
> > https://github.com/apache/incubator-mxnet/issues/11171 and
> > > > https://github.com/apache/incubator-mxnet/pull/10817.
> > > >
> > > > The pull request has been self-merged without proper review and
> > > introduced
> > > > regressions. Committers should act as role models in this project
> > and
> > > > adhere to software engineer best practices.
> > > >
> > > > Best regards,
> > > > Marco
> > > >
> > >
> >
> >
> >
>

Re: Reverting pull request

[Mu Li]

Agree that major changes need more extensive reviews. But we cannot ignore
that both reviews and CI cannot catch all bugs. Reverting each PR after
finding a bug should be the last ways, before it, we should try to fix it
first.

As for the breaking change, I see it differently. It breaks a not
recommended usage of the API from an unmaintained tutorial, I don't think
adding more reviewers will help it.

Besides, I'm less sure if we can find enough reviewers to provide useful
feedbacks for major changes.

On Fri, Jun 15, 2018 at 2:21 PM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> We revert a PR because it should not have been merged in the first place.
> So far, I have been ignoring the fact that our committers are constantly
> breaking our own rules (which we expect contributors to follow). But since
> this caused an impact twice (1.2 breaking change about model import/export
> as well as this regression), I'm now being more strict and enforcing them.
>
> I could've also made a script that prevents any PR from being self-merged,
> but I thought our committers are responsible enough to follow our own rules
> without systems actually enforcing them. I won't waste my time working on
> that script, but from now on I will revert every single PR (except
> emergency cases) that has been self-merged without approval.
>
> -Marco
>
> On Fri, Jun 15, 2018 at 2:15 PM Mu Li  wrote:
>
> > Why reverting instead of fixing the bugs? Static memory aims to reduce
> > memory allocation, it's a key feature to bridge the perf gap between
> gluon
> > and symbol.
> >
> > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > marco.g.ab...@googlemail.com.invalid> wrote:
> >
> > > Hello,
> > >
> > > I'm reverting https://github.com/apache/incubator-mxnet/pull/10817 as
> of
> > > https://github.com/apache/incubator-mxnet/pull/11311 due to
> regressions
> > > described in https://github.com/apache/incubator-mxnet/issues/11171
> and
> > > https://github.com/apache/incubator-mxnet/pull/10817.
> > >
> > > The pull request has been self-merged without proper review and
> > introduced
> > > regressions. Committers should act as role models in this project and
> > > adhere to software engineer best practices.
> > >
> > > Best regards,
> > > Marco
> > >
> >
>

Re: Reverting pull request

[Eric Xie]

Hi Marco de Abreu,

CI has been totally broken recently. It randomly fails for no good reason more 
often than it passes. For example the ccache/efs failure has been really 
annoying.

Looks like there has been many changes to Jenkins and Docker lately. Do you 
think we should revert all of the recent changes to get a stable CI or do you 
think someone should find a fix for the bugs?

Thanks,
Eric

On 2018/06/15 21:21:50, Marco de Abreu  
wrote: 
> We revert a PR because it should not have been merged in the first place.
> So far, I have been ignoring the fact that our committers are constantly
> breaking our own rules (which we expect contributors to follow). But since
> this caused an impact twice (1.2 breaking change about model import/export
> as well as this regression), I'm now being more strict and enforcing them.
> 
> I could've also made a script that prevents any PR from being self-merged,
> but I thought our committers are responsible enough to follow our own rules
> without systems actually enforcing them. I won't waste my time working on
> that script, but from now on I will revert every single PR (except
> emergency cases) that has been self-merged without approval.
> 
> -Marco
> 
> On Fri, Jun 15, 2018 at 2:15 PM Mu Li  wrote:
> 
> > Why reverting instead of fixing the bugs? Static memory aims to reduce
> > memory allocation, it's a key feature to bridge the perf gap between gluon
> > and symbol.
> >
> > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > marco.g.ab...@googlemail.com.invalid> wrote:
> >
> > > Hello,
> > >
> > > I'm reverting https://github.com/apache/incubator-mxnet/pull/10817 as of
> > > https://github.com/apache/incubator-mxnet/pull/11311 due to regressions
> > > described in https://github.com/apache/incubator-mxnet/issues/11171 and
> > > https://github.com/apache/incubator-mxnet/pull/10817.
> > >
> > > The pull request has been self-merged without proper review and
> > introduced
> > > regressions. Committers should act as role models in this project and
> > > adhere to software engineer best practices.
> > >
> > > Best regards,
> > > Marco
> > >
> >
> 

Re: Reverting pull request

[Haibin Lin]

Why revert the PR when we know there's a fix?
If we keep going backwards like this, no progress can be made.

On Fri, Jun 15, 2018 at 2:37 PM, Mu Li  wrote:

> Agree that major changes need more extensive reviews. But we cannot ignore
> that both reviews and CI cannot catch all bugs. Reverting each PR after
> finding a bug should be the last ways, before it, we should try to fix it
> first.
>
> As for the breaking change, I see it differently. It breaks a not
> recommended usage of the API from an unmaintained tutorial, I don't think
> adding more reviewers will help it.
>
> Besides, I'm less sure if we can find enough reviewers to provide useful
> feedbacks for major changes.
>
> On Fri, Jun 15, 2018 at 2:21 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
> > We revert a PR because it should not have been merged in the first place.
> > So far, I have been ignoring the fact that our committers are constantly
> > breaking our own rules (which we expect contributors to follow). But
> since
> > this caused an impact twice (1.2 breaking change about model
> import/export
> > as well as this regression), I'm now being more strict and enforcing
> them.
> >
> > I could've also made a script that prevents any PR from being
> self-merged,
> > but I thought our committers are responsible enough to follow our own
> rules
> > without systems actually enforcing them. I won't waste my time working on
> > that script, but from now on I will revert every single PR (except
> > emergency cases) that has been self-merged without approval.
> >
> > -Marco
> >
> > On Fri, Jun 15, 2018 at 2:15 PM Mu Li  wrote:
> >
> > > Why reverting instead of fixing the bugs? Static memory aims to reduce
> > > memory allocation, it's a key feature to bridge the perf gap between
> > gluon
> > > and symbol.
> > >
> > > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > > marco.g.ab...@googlemail.com.invalid> wrote:
> > >
> > > > Hello,
> > > >
> > > > I'm reverting https://github.com/apache/incubator-mxnet/pull/10817
> as
> > of
> > > > https://github.com/apache/incubator-mxnet/pull/11311 due to
> > regressions
> > > > described in https://github.com/apache/incubator-mxnet/issues/11171
> > and
> > > > https://github.com/apache/incubator-mxnet/pull/10817.
> > > >
> > > > The pull request has been self-merged without proper review and
> > > introduced
> > > > regressions. Committers should act as role models in this project and
> > > > adhere to software engineer best practices.
> > > >
> > > > Best regards,
> > > > Marco
> > > >
> > >
> >
>

Re: Reverting pull request

[Marco de Abreu]

We have the rule that a pull request must receive an approval from at least
one committer and that they must have test coverage. Both rules have been
broken multiple times. I view this situation independent of the actual bug
but just from the fact that it has been self-merged without approval. About
"but a proper way
would bring this issue up friendly": I don't know how often we already said
that this should be stopped, but there were still committers who merged
their own PRs.

This whole discussion would have been obsolete if the rules we've set up
ourselves would have been followed. The fact that this introduced a bug was
just the little push that brought this topic higher on my priority list.

I'm very sorry for any inconveniences this may cause, but next time we
should just stick to our own rules.

-Marco

On Fri, Jun 15, 2018 at 2:37 PM Mu Li  wrote:

> Agree that major changes need more extensive reviews. But we cannot ignore
> that both reviews and CI cannot catch all bugs. Reverting each PR after
> finding a bug should be the last ways, before it, we should try to fix it
> first.
>
> As for the breaking change, I see it differently. It breaks a not
> recommended usage of the API from an unmaintained tutorial, I don't think
> adding more reviewers will help it.
>
> Besides, I'm less sure if we can find enough reviewers to provide useful
> feedbacks for major changes.
>
> On Fri, Jun 15, 2018 at 2:21 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
> > We revert a PR because it should not have been merged in the first place.
> > So far, I have been ignoring the fact that our committers are constantly
> > breaking our own rules (which we expect contributors to follow). But
> since
> > this caused an impact twice (1.2 breaking change about model
> import/export
> > as well as this regression), I'm now being more strict and enforcing
> them.
> >
> > I could've also made a script that prevents any PR from being
> self-merged,
> > but I thought our committers are responsible enough to follow our own
> rules
> > without systems actually enforcing them. I won't waste my time working on
> > that script, but from now on I will revert every single PR (except
> > emergency cases) that has been self-merged without approval.
> >
> > -Marco
> >
> > On Fri, Jun 15, 2018 at 2:15 PM Mu Li  wrote:
> >
> > > Why reverting instead of fixing the bugs? Static memory aims to reduce
> > > memory allocation, it's a key feature to bridge the perf gap between
> > gluon
> > > and symbol.
> > >
> > > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > > marco.g.ab...@googlemail.com.invalid> wrote:
> > >
> > > > Hello,
> > > >
> > > > I'm reverting https://github.com/apache/incubator-mxnet/pull/10817
> as
> > of
> > > > https://github.com/apache/incubator-mxnet/pull/11311 due to
> > regressions
> > > > described in https://github.com/apache/incubator-mxnet/issues/11171
> > and
> > > > https://github.com/apache/incubator-mxnet/pull/10817.
> > > >
> > > > The pull request has been self-merged without proper review and
> > > introduced
> > > > regressions. Committers should act as role models in this project and
> > > > adhere to software engineer best practices.
> > > >
> > > > Best regards,
> > > > Marco
> > > >
> > >
> >
>

Reverting pull request

[Marco de Abreu]

Hello,

I'm reverting https://github.com/apache/incubator-mxnet/pull/10817 as of
https://github.com/apache/incubator-mxnet/pull/11311 due to regressions
described in https://github.com/apache/incubator-mxnet/issues/11171 and
https://github.com/apache/incubator-mxnet/pull/10817.

The pull request has been self-merged without proper review and introduced
regressions. Committers should act as role models in this project and
adhere to software engineer best practices.

Best regards,
Marco

Re: MXNet issues labeling

[Qing Lan]

Hi All,
I would like to quote this:
```
Cathy:
I am working on this label bot to automate/simplify this labeling issue
process and send weekly report to maintainers. Design proposal is on cwiki:
https://cwiki.apache.org/confluence/display/MXNET/Deep+Learning+Based+GitHub+Label+Bot

Please feel free to let me know if you have
suggestions/requirements/expectations.

Thanks,
Cathy
```
Currently Cathy has done the design for labelling the issues and I believe that 
will help our community to track more issues quickly. 
Since we received a lot of +1s from this list last time, I would like to ask 
for a Label adding/removing permission for the bot that Cathy designed. 
Can we do something like this for a GitHub account?

Thanks,
Qing

On 5/22/18, 9:56 AM, "Roshani Nagmote"  wrote:

Sorry for incomplete email. Sent it too fast.
Thanks for all the comments. Aaron guessed it right. We can treat it as a
multi-label classification problem. :)
We are currently working on the design document, will share it on dev list
once it is more concrete.

@Marco, seems like a good idea too but as you said, it will still involve
manual labeling. We can do this as a temporary solution but need a
long-term solution.
@Hao, will explore that option too! Thanks!

Thanks,
Roshani


On Tue, May 22, 2018 at 9:52 AM, Roshani Nagmote 
wrote:

> Thanks for all the comments. Aaron guessed it right. We can treat it as a
> multi-label classification problem. :)
> We are currently working on the design document, will share it on dev list
> once it is more concrete.
>
> @Marco, seems like a good idea too but as you said, it will still involve
> manual labeling. We can do this as a temporary solution but need a more
> @Hao, will explore that option too! Thanks!
>
> Thanks,
> Roshani
>
> On Mon, May 21, 2018 at 5:42 PM, Jin, Hao  wrote:
>
>> Definitely a good idea. I think maybe we can also try out the new gluon
>> NLP toolkit on this task?
>>
>> On 5/21/18, 5:24 PM, "Anirudh"  wrote:
>>
>> Yes, I guessed that :). Was looking for more details.
>>
>> On Mon, May 21, 2018 at 5:03 PM, Aaron Markham <
>> aaron.s.mark...@gmail.com>
>> wrote:
>>
>> > AI obviously.
>> >
>> > On Mon, May 21, 2018 at 5:01 PM, Anirudh 
>> wrote:
>> >
>> > > Hi Roshani,
>> > >
>> > > Good suggestion! How will the bot decide what labels to add ?
>> > >
>> > > Anirudh
>> > >
>> > > On Mon, May 21, 2018 at 4:39 PM, Naveen Swamy > >
>> > wrote:
>> > >
>> > > > +1 for the proposal to triage issues, I think committers should
>> also do
>> > > > this exercise to understand the customer pain.
>> > > >
>> > > > I am also inclined to use a bot account like how Tensorflow and
>> other
>> > > repos
>> > > > do it, https://github.com/googlebot.
>> > > > https://github.com/tensorflow/tensorflow/pull/19445#event-16
>> 38027271
>> > -->
>> > > > This is auto-tagged by the bot, it would be cool if we could do
>> that as
>> > > > well.
>> > > >
>> > > >
>> > > >
>> > > > On Mon, May 21, 2018 at 4:25 PM, sandeep krishnamurthy <
>> > > > sandeep.krishn...@gmail.com> wrote:
>> > > >
>> > > > > Thanks,
>> > > > >
>> > > > > Roshani for starting this thread.
>> > > > >
>> > > > > Yes, I think labeling the issues will help a lot in driving
>> the
>> > > attention
>> > > > > of contributors to specific areas and make it easy for new
>> > contributors
>> > > > to
>> > > > > search and pick their contribution.
>> > > > >
>> > > > > I agree manually doing it all the time is not scalable and
>> efficient.
>> > > > Your
>> > > > > proposal on bot script to auto-label, similar to the working
>> of
>> > Jenkins
>> > > > bot
>> > > > > to re-test, re-build actions, will be very useful and
>> effective.
>> > > Hence, I
>> > > > > am more inclined to your *option 1* to have a bot account to
>> add
>> > > labels.
>> > > > >
>> > > > > Best,
>> > > > > Sandeep
>> > > > >
>> > > > > On Mon, May 21, 2018 at 4:16 PM, Roshani Nagmote <
>> > > > > roshaninagmo...@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > Some of us here at Amazon as a part of our day job, are
>> triaging
>> > > Github
>> > > > > > issues to find where MXNet users are experiencing
>> difficulty and
>> > help
>> > > > the
>> > > > > > community focus on those areas. This 

Re: Reverting pull request

[Mu Li]

Why reverting instead of fixing the bugs? Static memory aims to reduce
memory allocation, it's a key feature to bridge the perf gap between gluon
and symbol.

On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> Hello,
>
> I'm reverting https://github.com/apache/incubator-mxnet/pull/10817 as of
> https://github.com/apache/incubator-mxnet/pull/11311 due to regressions
> described in https://github.com/apache/incubator-mxnet/issues/11171 and
> https://github.com/apache/incubator-mxnet/pull/10817.
>
> The pull request has been self-merged without proper review and introduced
> regressions. Committers should act as role models in this project and
> adhere to software engineer best practices.
>
> Best regards,
> Marco
>

Re: Update on 1.2.1 release

[Marco de Abreu]

Hello,

we would need this PR to be merged as well:
https://github.com/apache/incubator-mxnet/pull/11309

With the next deployment of new Windows slaves (which should happen asap),
the 1.2 branch and all past branches are going to break since the test
execution is not versioned. Please merge this PR to ensure we're still able
to test the 1.2 branch on our CI.

-Marco

On Thu, Jun 14, 2018 at 6:20 PM Anirudh  wrote:

> Hi all,
>
> We have one last PR before code freeze:
> https://github.com/apache/incubator-mxnet/pull/11298
>
> Anirudh
>
> On Thu, Jun 14, 2018 at 11:46 AM, Anirudh  wrote:
>
> > Waiting on CI for the PRs: #11236, #11210, #11267
> >
> > Other PRs have been merged.
> >
> > On Wed, Jun 13, 2018 at 10:50 PM, Anirudh  wrote:
> >
> >> Thanks Tao! Yes, this shouldn't be a blocker for 1.2.1.
> >>
> >> On Wed, Jun 13, 2018 at 10:46 PM, Lv, Tao A  wrote:
> >>
> >>>
> >>> Yes, #10311 is only in master branch, so I guess it won't impact 1.2.0
> >>> branch and block the release of 1.2.1, right?
> >>>
> >>> A PR (#11273) is submitted to disable the test temporally and hopefully
> >>> it will be fixed soon.
> >>>
> >>> -tao
> >>>
> >>> -Original Message-
> >>> From: Marco de Abreu [mailto:marco.g.ab...@googlemail.com.INVALID]
> >>> Sent: Thursday, June 14, 2018 1:21 PM
> >>> To: dev@mxnet.incubator.apache.org
> >>> Subject: Re: Update on 1.2.1 release
> >>>
> >>> On windows tests a segfault is indicated by "If -764728474728". I have
> >>> also seen it happen on Ubuntu, there are probably some links in the
> issue
> >>> (on my phone right now).
> >>>
> >>> Anirudh  schrieb am Mi., 13. Juni 2018, 22:16:
> >>>
> >>> > By segfaulting test do you mean : test_gru_bidirectional. I don't see
> >>> > the segfault in the logs. Can you point me to the test.
> >>> > Also, this seems to be specific to the master and not in 1.2:
> >>> > https://github.com/apache/incubator-mxnet/pull/10311
> >>> >
> >>> > Anirudh
> >>> >
> >>> > On Wed, Jun 13, 2018 at 10:00 PM, Marco de Abreu <
> >>> > marco.g.ab...@googlemail.com.invalid> wrote:
> >>> >
> >>> > > I can confirm that this segfaulting test has a big impact.
> >>> > >
> >>> > > On Wed, Jun 13, 2018 at 9:39 PM Aaron Markham
> >>> > >  >>> > >
> >>> > > wrote:
> >>> > >
> >>> > > > I'd keep an eye on this one...  Flaky test:
> test_gru_bidirectional
> >>> > #11219
> >>> > > >
> >>> > > > https://github.com/apache/incubator-mxnet/issues/11219
> >>> > > >
> >>> > > > Just reran several PR's CI runs that all had the same error!
> >>> > > >
> >>> > > > On Wed, Jun 13, 2018 at 5:42 PM, Anirudh 
> >>> > wrote:
> >>> > > >
> >>> > > > > Hi,
> >>> > > > >
> >>> > > > > PRs still in progress : #11127, #11236, #11210, #11054, #11216.
> >>> > > > >
> >>> > > > > We are currently facing two issues which are delaying the merge
> >>> > > > > of
> >>> > some
> >>> > > > of
> >>> > > > > these PRs:
> >>> > > > > 1. Flaky tests for scala API. A PR is already out to disable
> the
> >>> > test:
> >>> > > > > https://github.com/apache/incubator-mxnet/issues/11249
> >>> > > > > 2. Builds breaking on windows:
> >>> > > > > https://github.com/apache/incubator-mxnet/issues/11265
> >>> > > > >
> >>> > > > > Anirudh
> >>> > > > >
> >>> > > > >
> >>> > > > > On Tue, Jun 12, 2018 at 11:59 AM, Anirudh
> >>> > > > > 
> >>> > > wrote:
> >>> > > > >
> >>> > > > > > Hi all,
> >>> > > > > >
> >>> > > > > > Here are the PRs that are being tracked for 1.2.1 release:
> >>> > > > > >
> >>> > > > > > Related to the save_params backwards incompatible change:
> >>> > > > > > #11127
> >>> > (In
> >>> > > > > > Progress), #11236 (In Progress), #11210 (In Progress) MKLDNN
> >>> > > > > > Fixes: #11212 (In Progress) Cross compilation for armv7 :
> >>> > > > > > #11054 (In Progress) Scala Inference Memory leak fix: #11216
> >>> > > > > > (In Progress) Docs changes: #11211 (Merged) Inplace RELU
> >>> > > > > > Activation, Slice operator perf improvement: #11142
> >>> > > > (Merged)
> >>> > > > > > Use cudnnv7 for depthwise conv #11233 (Merged)
> >>> > > > > >
> >>> > > > > > Please let me know if I have missed something.
> >>> > > > > >
> >>> > > > > > Anirudh
> >>> > > > > >
> >>> > > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>

Re: Reverting pull request

[Chris Olivier]

does anyone know how to unsubscribe from this list?


On Fri, Jun 15, 2018 at 2:56 PM Haibin Lin  wrote:

> Why revert the PR when we know there's a fix?
> If we keep going backwards like this, no progress can be made.
>
> On Fri, Jun 15, 2018 at 2:37 PM, Mu Li  wrote:
>
> > Agree that major changes need more extensive reviews. But we cannot
> ignore
> > that both reviews and CI cannot catch all bugs. Reverting each PR after
> > finding a bug should be the last ways, before it, we should try to fix it
> > first.
> >
> > As for the breaking change, I see it differently. It breaks a not
> > recommended usage of the API from an unmaintained tutorial, I don't think
> > adding more reviewers will help it.
> >
> > Besides, I'm less sure if we can find enough reviewers to provide useful
> > feedbacks for major changes.
> >
> > On Fri, Jun 15, 2018 at 2:21 PM, Marco de Abreu <
> > marco.g.ab...@googlemail.com.invalid> wrote:
> >
> > > We revert a PR because it should not have been merged in the first
> place.
> > > So far, I have been ignoring the fact that our committers are
> constantly
> > > breaking our own rules (which we expect contributors to follow). But
> > since
> > > this caused an impact twice (1.2 breaking change about model
> > import/export
> > > as well as this regression), I'm now being more strict and enforcing
> > them.
> > >
> > > I could've also made a script that prevents any PR from being
> > self-merged,
> > > but I thought our committers are responsible enough to follow our own
> > rules
> > > without systems actually enforcing them. I won't waste my time working
> on
> > > that script, but from now on I will revert every single PR (except
> > > emergency cases) that has been self-merged without approval.
> > >
> > > -Marco
> > >
> > > On Fri, Jun 15, 2018 at 2:15 PM Mu Li  wrote:
> > >
> > > > Why reverting instead of fixing the bugs? Static memory aims to
> reduce
> > > > memory allocation, it's a key feature to bridge the perf gap between
> > > gluon
> > > > and symbol.
> > > >
> > > > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > > > marco.g.ab...@googlemail.com.invalid> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I'm reverting https://github.com/apache/incubator-mxnet/pull/10817
> > as
> > > of
> > > > > https://github.com/apache/incubator-mxnet/pull/11311 due to
> > > regressions
> > > > > described in
> https://github.com/apache/incubator-mxnet/issues/11171
> > > and
> > > > > https://github.com/apache/incubator-mxnet/pull/10817.
> > > > >
> > > > > The pull request has been self-merged without proper review and
> > > > introduced
> > > > > regressions. Committers should act as role models in this project
> and
> > > > > adhere to software engineer best practices.
> > > > >
> > > > > Best regards,
> > > > > Marco
> > > > >
> > > >
> > >
> >
>

Re: Reverting pull request

[Naveen Swamy]

Moving this to private, I don't want our contributors to get discouraged by
our internal bickering.

Mu, we have to start somewhere..your comment "find enough reviewers to
provide useful feedbacks for major changes." is pretty condescending and I
take objection to it.

By now Eric, you and Tianqi are considered super Hero of MXNet(no malafide
intended) and if you want to become Super hero of AI, you have to grow the
knowledge base of the community on the code base instead of thinking these
guys will not provide any valid input and asking questions in moderation is
not a bad place to start many don't participate in the PR process because
you guys are super rude and condescending like this..

I have not seen any discussion on the dev list or a design about this
feature addition? did I miss it?

I like what Tianqi said about moving forward but we cannot just make this a
norm..

Also I would like to request all committers to bring up controversial
topics on the private list and not drive away contributors outside of dmlc
and Amazon.



On Fri, Jun 15, 2018 at 11:59 PM, Chris Olivier 
wrote:

> does anyone know how to unsubscribe from this list?
>
>
> On Fri, Jun 15, 2018 at 2:56 PM Haibin Lin 
> wrote:
>
> > Why revert the PR when we know there's a fix?
> > If we keep going backwards like this, no progress can be made.
> >
> > On Fri, Jun 15, 2018 at 2:37 PM, Mu Li  wrote:
> >
> > > Agree that major changes need more extensive reviews. But we cannot
> > ignore
> > > that both reviews and CI cannot catch all bugs. Reverting each PR after
> > > finding a bug should be the last ways, before it, we should try to fix
> it
> > > first.
> > >
> > > As for the breaking change, I see it differently. It breaks a not
> > > recommended usage of the API from an unmaintained tutorial, I don't
> think
> > > adding more reviewers will help it.
> > >
> > > Besides, I'm less sure if we can find enough reviewers to provide
> useful
> > > feedbacks for major changes.
> > >
> > > On Fri, Jun 15, 2018 at 2:21 PM, Marco de Abreu <
> > > marco.g.ab...@googlemail.com.invalid> wrote:
> > >
> > > > We revert a PR because it should not have been merged in the first
> > place.
> > > > So far, I have been ignoring the fact that our committers are
> > constantly
> > > > breaking our own rules (which we expect contributors to follow). But
> > > since
> > > > this caused an impact twice (1.2 breaking change about model
> > > import/export
> > > > as well as this regression), I'm now being more strict and enforcing
> > > them.
> > > >
> > > > I could've also made a script that prevents any PR from being
> > > self-merged,
> > > > but I thought our committers are responsible enough to follow our own
> > > rules
> > > > without systems actually enforcing them. I won't waste my time
> working
> > on
> > > > that script, but from now on I will revert every single PR (except
> > > > emergency cases) that has been self-merged without approval.
> > > >
> > > > -Marco
> > > >
> > > > On Fri, Jun 15, 2018 at 2:15 PM Mu Li  wrote:
> > > >
> > > > > Why reverting instead of fixing the bugs? Static memory aims to
> > reduce
> > > > > memory allocation, it's a key feature to bridge the perf gap
> between
> > > > gluon
> > > > > and symbol.
> > > > >
> > > > > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > > > > marco.g.ab...@googlemail.com.invalid> wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I'm reverting https://github.com/apache/
> incubator-mxnet/pull/10817
> > > as
> > > > of
> > > > > > https://github.com/apache/incubator-mxnet/pull/11311 due to
> > > > regressions
> > > > > > described in
> > https://github.com/apache/incubator-mxnet/issues/11171
> > > > and
> > > > > > https://github.com/apache/incubator-mxnet/pull/10817.
> > > > > >
> > > > > > The pull request has been self-merged without proper review and
> > > > > introduced
> > > > > > regressions. Committers should act as role models in this project
> > and
> > > > > > adhere to software engineer best practices.
> > > > > >
> > > > > > Best regards,
> > > > > > Marco
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Reverting pull request

[Mu Li]

send to

*dev*-*un*subscr...@mxnet.incubator.apache.org


On Fri, Jun 15, 2018 at 2:59 PM, Chris Olivier 
wrote:

> does anyone know how to unsubscribe from this list?
>
>
> On Fri, Jun 15, 2018 at 2:56 PM Haibin Lin 
> wrote:
>
> > Why revert the PR when we know there's a fix?
> > If we keep going backwards like this, no progress can be made.
> >
> > On Fri, Jun 15, 2018 at 2:37 PM, Mu Li  wrote:
> >
> > > Agree that major changes need more extensive reviews. But we cannot
> > ignore
> > > that both reviews and CI cannot catch all bugs. Reverting each PR after
> > > finding a bug should be the last ways, before it, we should try to fix
> it
> > > first.
> > >
> > > As for the breaking change, I see it differently. It breaks a not
> > > recommended usage of the API from an unmaintained tutorial, I don't
> think
> > > adding more reviewers will help it.
> > >
> > > Besides, I'm less sure if we can find enough reviewers to provide
> useful
> > > feedbacks for major changes.
> > >
> > > On Fri, Jun 15, 2018 at 2:21 PM, Marco de Abreu <
> > > marco.g.ab...@googlemail.com.invalid> wrote:
> > >
> > > > We revert a PR because it should not have been merged in the first
> > place.
> > > > So far, I have been ignoring the fact that our committers are
> > constantly
> > > > breaking our own rules (which we expect contributors to follow). But
> > > since
> > > > this caused an impact twice (1.2 breaking change about model
> > > import/export
> > > > as well as this regression), I'm now being more strict and enforcing
> > > them.
> > > >
> > > > I could've also made a script that prevents any PR from being
> > > self-merged,
> > > > but I thought our committers are responsible enough to follow our own
> > > rules
> > > > without systems actually enforcing them. I won't waste my time
> working
> > on
> > > > that script, but from now on I will revert every single PR (except
> > > > emergency cases) that has been self-merged without approval.
> > > >
> > > > -Marco
> > > >
> > > > On Fri, Jun 15, 2018 at 2:15 PM Mu Li  wrote:
> > > >
> > > > > Why reverting instead of fixing the bugs? Static memory aims to
> > reduce
> > > > > memory allocation, it's a key feature to bridge the perf gap
> between
> > > > gluon
> > > > > and symbol.
> > > > >
> > > > > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > > > > marco.g.ab...@googlemail.com.invalid> wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I'm reverting https://github.com/apache/
> incubator-mxnet/pull/10817
> > > as
> > > > of
> > > > > > https://github.com/apache/incubator-mxnet/pull/11311 due to
> > > > regressions
> > > > > > described in
> > https://github.com/apache/incubator-mxnet/issues/11171
> > > > and
> > > > > > https://github.com/apache/incubator-mxnet/pull/10817.
> > > > > >
> > > > > > The pull request has been self-merged without proper review and
> > > > > introduced
> > > > > > regressions. Committers should act as role models in this project
> > and
> > > > > > adhere to software engineer best practices.
> > > > > >
> > > > > > Best regards,
> > > > > > Marco
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Reverting pull request

[Marco de Abreu]

CI doesn't fail for no reason but because some people prefer to push new
features than to get our codebase actually stable. We currently have 51 [1]
flaky tests and I have only seen a few people (thanks Sheng, Alex and
Pedro) work on the problem. So instead of complaining, take part and help
improving the situation.

The CCache/EFS failure lasted for 12 hours and was an error - these things
happen when you run a service. This is not a blame-game.

-Marco

[1]:
https://github.com/apache/incubator-mxnet/issues?q=is%3Aopen+is%3Aissue+label%3AFlaky

On Fri, Jun 15, 2018 at 2:55 PM Eric Xie  wrote:

> Hi Marco de Abreu,
>
> CI has been totally broken recently. It randomly fails for no good reason
> more often than it passes. For example the ccache/efs failure has been
> really annoying.
>
> Looks like there has been many changes to Jenkins and Docker lately. Do
> you think we should revert all of the recent changes to get a stable CI or
> do you think someone should find a fix for the bugs?
>
> Thanks,
> Eric
>
> On 2018/06/15 21:21:50, Marco de Abreu 
> wrote:
> > We revert a PR because it should not have been merged in the first place.
> > So far, I have been ignoring the fact that our committers are constantly
> > breaking our own rules (which we expect contributors to follow). But
> since
> > this caused an impact twice (1.2 breaking change about model
> import/export
> > as well as this regression), I'm now being more strict and enforcing
> them.
> >
> > I could've also made a script that prevents any PR from being
> self-merged,
> > but I thought our committers are responsible enough to follow our own
> rules
> > without systems actually enforcing them. I won't waste my time working on
> > that script, but from now on I will revert every single PR (except
> > emergency cases) that has been self-merged without approval.
> >
> > -Marco
> >
> > On Fri, Jun 15, 2018 at 2:15 PM Mu Li  wrote:
> >
> > > Why reverting instead of fixing the bugs? Static memory aims to reduce
> > > memory allocation, it's a key feature to bridge the perf gap between
> gluon
> > > and symbol.
> > >
> > > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > > marco.g.ab...@googlemail.com.invalid> wrote:
> > >
> > > > Hello,
> > > >
> > > > I'm reverting https://github.com/apache/incubator-mxnet/pull/10817
> as of
> > > > https://github.com/apache/incubator-mxnet/pull/11311 due to
> regressions
> > > > described in https://github.com/apache/incubator-mxnet/issues/11171
> and
> > > > https://github.com/apache/incubator-mxnet/pull/10817.
> > > >
> > > > The pull request has been self-merged without proper review and
> > > introduced
> > > > regressions. Committers should act as role models in this project and
> > > > adhere to software engineer best practices.
> > > >
> > > > Best regards,
> > > > Marco
> > > >
> > >
> >
>

Re: Reverting pull request

[Eric Xie]

The way I see it:

1) you are just complaining and have never written code that fixes flaky tests
2) you are actively introducing bugs to the CI that causes it to fail in ways 
unrelated to any tests

Eric

On 2018/06/15 22:03:29, Marco de Abreu  
wrote: 
> CI doesn't fail for no reason but because some people prefer to push new
> features than to get our codebase actually stable. We currently have 51 [1]
> flaky tests and I have only seen a few people (thanks Sheng, Alex and
> Pedro) work on the problem. So instead of complaining, take part and help
> improving the situation.
> 
> The CCache/EFS failure lasted for 12 hours and was an error - these things
> happen when you run a service. This is not a blame-game.
> 
> -Marco
> 
> [1]:
> https://github.com/apache/incubator-mxnet/issues?q=is%3Aopen+is%3Aissue+label%3AFlaky
> 
> On Fri, Jun 15, 2018 at 2:55 PM Eric Xie  wrote:
> 
> > Hi Marco de Abreu,
> >
> > CI has been totally broken recently. It randomly fails for no good reason
> > more often than it passes. For example the ccache/efs failure has been
> > really annoying.
> >
> > Looks like there has been many changes to Jenkins and Docker lately. Do
> > you think we should revert all of the recent changes to get a stable CI or
> > do you think someone should find a fix for the bugs?
> >
> > Thanks,
> > Eric
> >
> > On 2018/06/15 21:21:50, Marco de Abreu 
> > 
> > wrote:
> > > We revert a PR because it should not have been merged in the first place.
> > > So far, I have been ignoring the fact that our committers are constantly
> > > breaking our own rules (which we expect contributors to follow). But
> > since
> > > this caused an impact twice (1.2 breaking change about model
> > import/export
> > > as well as this regression), I'm now being more strict and enforcing
> > them.
> > >
> > > I could've also made a script that prevents any PR from being
> > self-merged,
> > > but I thought our committers are responsible enough to follow our own
> > rules
> > > without systems actually enforcing them. I won't waste my time working on
> > > that script, but from now on I will revert every single PR (except
> > > emergency cases) that has been self-merged without approval.
> > >
> > > -Marco
> > >
> > > On Fri, Jun 15, 2018 at 2:15 PM Mu Li  wrote:
> > >
> > > > Why reverting instead of fixing the bugs? Static memory aims to reduce
> > > > memory allocation, it's a key feature to bridge the perf gap between
> > gluon
> > > > and symbol.
> > > >
> > > > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > > > marco.g.ab...@googlemail.com.invalid> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I'm reverting https://github.com/apache/incubator-mxnet/pull/10817
> > as of
> > > > > https://github.com/apache/incubator-mxnet/pull/11311 due to
> > regressions
> > > > > described in https://github.com/apache/incubator-mxnet/issues/11171
> > and
> > > > > https://github.com/apache/incubator-mxnet/pull/10817.
> > > > >
> > > > > The pull request has been self-merged without proper review and
> > > > introduced
> > > > > regressions. Committers should act as role models in this project and
> > > > > adhere to software engineer best practices.
> > > > >
> > > > > Best regards,
> > > > > Marco
> > > > >
> > > >
> > >
> >
> 

Re: Reverting pull request

[Mu Li]

Hi Marco,

You really want to bring it into Amazon internal planning meeting. I have
been requesting to focus on fixing bugs for several weeks, instead of
adding new features. But I didn't get a concrete time when it will happen.

Best
Mu

On Fri, Jun 15, 2018 at 3:03 PM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> CI doesn't fail for no reason but because some people prefer to push new
> features than to get our codebase actually stable. We currently have 51 [1]
> flaky tests and I have only seen a few people (thanks Sheng, Alex and
> Pedro) work on the problem. So instead of complaining, take part and help
> improving the situation.
>
> The CCache/EFS failure lasted for 12 hours and was an error - these things
> happen when you run a service. This is not a blame-game.
>
> -Marco
>
> [1]:
> https://github.com/apache/incubator-mxnet/issues?q=is%
> 3Aopen+is%3Aissue+label%3AFlaky
>
> On Fri, Jun 15, 2018 at 2:55 PM Eric Xie  wrote:
>
> > Hi Marco de Abreu,
> >
> > CI has been totally broken recently. It randomly fails for no good reason
> > more often than it passes. For example the ccache/efs failure has been
> > really annoying.
> >
> > Looks like there has been many changes to Jenkins and Docker lately. Do
> > you think we should revert all of the recent changes to get a stable CI
> or
> > do you think someone should find a fix for the bugs?
> >
> > Thanks,
> > Eric
> >
> > On 2018/06/15 21:21:50, Marco de Abreu  INVALID>
> > wrote:
> > > We revert a PR because it should not have been merged in the first
> place.
> > > So far, I have been ignoring the fact that our committers are
> constantly
> > > breaking our own rules (which we expect contributors to follow). But
> > since
> > > this caused an impact twice (1.2 breaking change about model
> > import/export
> > > as well as this regression), I'm now being more strict and enforcing
> > them.
> > >
> > > I could've also made a script that prevents any PR from being
> > self-merged,
> > > but I thought our committers are responsible enough to follow our own
> > rules
> > > without systems actually enforcing them. I won't waste my time working
> on
> > > that script, but from now on I will revert every single PR (except
> > > emergency cases) that has been self-merged without approval.
> > >
> > > -Marco
> > >
> > > On Fri, Jun 15, 2018 at 2:15 PM Mu Li  wrote:
> > >
> > > > Why reverting instead of fixing the bugs? Static memory aims to
> reduce
> > > > memory allocation, it's a key feature to bridge the perf gap between
> > gluon
> > > > and symbol.
> > > >
> > > > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > > > marco.g.ab...@googlemail.com.invalid> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I'm reverting https://github.com/apache/incubator-mxnet/pull/10817
> > as of
> > > > > https://github.com/apache/incubator-mxnet/pull/11311 due to
> > regressions
> > > > > described in https://github.com/apache/
> incubator-mxnet/issues/11171
> > and
> > > > > https://github.com/apache/incubator-mxnet/pull/10817.
> > > > >
> > > > > The pull request has been self-merged without proper review and
> > > > introduced
> > > > > regressions. Committers should act as role models in this project
> and
> > > > > adhere to software engineer best practices.
> > > > >
> > > > > Best regards,
> > > > > Marco
> > > > >
> > > >
> > >
> >
>

Re: Reverting pull request

[Anirudh]

Hi,

We can have a separate discussion on whether this was a friendly way to
bring this up or not,
but I don't see why we shouldn't roll back, share design on dev, fix the
bug and add performance benchmarking results and call for reviews on
a new PR. This seems to be a big change which was introduced and I have
seen Eric himself rolling back PRs
for big changes which happen to have a regression or insufficient tests. To
quote Eric from here
https://github.com/apache/incubator-mxnet/pull/8010 : "Roll
back is always better than fix forward."
I agree with Marco that we should abide by the rules which we set for other
contributors.
If the argument is that users depend on the change since it has been
introduced a few days ago, then the assumption with depending on the master
is always that it is bleeding edge and things can break.

Anirudh

On Fri, Jun 15, 2018 at 3:10 PM, Mu Li  wrote:

> Hi Marco,
>
> You really want to bring it into Amazon internal planning meeting. I have
> been requesting to focus on fixing bugs for several weeks, instead of
> adding new features. But I didn't get a concrete time when it will happen.
>
> Best
> Mu
>
> On Fri, Jun 15, 2018 at 3:03 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
> > CI doesn't fail for no reason but because some people prefer to push new
> > features than to get our codebase actually stable. We currently have 51
> [1]
> > flaky tests and I have only seen a few people (thanks Sheng, Alex and
> > Pedro) work on the problem. So instead of complaining, take part and help
> > improving the situation.
> >
> > The CCache/EFS failure lasted for 12 hours and was an error - these
> things
> > happen when you run a service. This is not a blame-game.
> >
> > -Marco
> >
> > [1]:
> > https://github.com/apache/incubator-mxnet/issues?q=is%
> > 3Aopen+is%3Aissue+label%3AFlaky
> >
> > On Fri, Jun 15, 2018 at 2:55 PM Eric Xie  wrote:
> >
> > > Hi Marco de Abreu,
> > >
> > > CI has been totally broken recently. It randomly fails for no good
> reason
> > > more often than it passes. For example the ccache/efs failure has been
> > > really annoying.
> > >
> > > Looks like there has been many changes to Jenkins and Docker lately. Do
> > > you think we should revert all of the recent changes to get a stable CI
> > or
> > > do you think someone should find a fix for the bugs?
> > >
> > > Thanks,
> > > Eric
> > >
> > > On 2018/06/15 21:21:50, Marco de Abreu  > INVALID>
> > > wrote:
> > > > We revert a PR because it should not have been merged in the first
> > place.
> > > > So far, I have been ignoring the fact that our committers are
> > constantly
> > > > breaking our own rules (which we expect contributors to follow). But
> > > since
> > > > this caused an impact twice (1.2 breaking change about model
> > > import/export
> > > > as well as this regression), I'm now being more strict and enforcing
> > > them.
> > > >
> > > > I could've also made a script that prevents any PR from being
> > > self-merged,
> > > > but I thought our committers are responsible enough to follow our own
> > > rules
> > > > without systems actually enforcing them. I won't waste my time
> working
> > on
> > > > that script, but from now on I will revert every single PR (except
> > > > emergency cases) that has been self-merged without approval.
> > > >
> > > > -Marco
> > > >
> > > > On Fri, Jun 15, 2018 at 2:15 PM Mu Li  wrote:
> > > >
> > > > > Why reverting instead of fixing the bugs? Static memory aims to
> > reduce
> > > > > memory allocation, it's a key feature to bridge the perf gap
> between
> > > gluon
> > > > > and symbol.
> > > > >
> > > > > On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu <
> > > > > marco.g.ab...@googlemail.com.invalid> wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I'm reverting https://github.com/apache/
> incubator-mxnet/pull/10817
> > > as of
> > > > > > https://github.com/apache/incubator-mxnet/pull/11311 due to
> > > regressions
> > > > > > described in https://github.com/apache/
> > incubator-mxnet/issues/11171
> > > and
> > > > > > https://github.com/apache/incubator-mxnet/pull/10817.
> > > > > >
> > > > > > The pull request has been self-merged without proper review and
> > > > > introduced
> > > > > > regressions. Committers should act as role models in this project
> > and
> > > > > > adhere to software engineer best practices.
> > > > > >
> > > > > > Best regards,
> > > > > > Marco
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Reverting pull request

[Lupesko, Hagay]

Hey all,

Although I am not a committer, and also have not contributed to MXNet as much 
as I would have wanted, wanted to chime in.
Based on my experience doing SW dev for quite some time, I think that holding a 
high bar for the code that gets merged is a very positive thing - including 
making sure all code that is merged is reviewed.
Yes - it slows you down a bit, and yes, some people may know certain areas of 
the code best, to the point they feel reviews are not helpful and slow them 
down But, getting eye balls on your code change is always a good thing that 
helps everyone improve: the author of the change, the reviewer and the code 
base itself. Not to mention it helps find issues and bugs that one person may 
miss.

Why merge code without a review, and if that happens accidentally or what not, 
why not revert, improve as needed (bugs, unit tests, etc) and then submit a new 
PR? 
Assuming this is not an urgent fix - I think that a revert is a better approach 
then leaving bugs in and gradually merging fixes.

On another note, this discussion became very heated and emotional, and does not 
make the MXNet community look good.
I suggest the folks involved to do in person video call and sort things out - 
everyone's in the same boat to make MXNet awesome, right?

Happy Friday everyone,
Hagay

On 6/15/18, 16:07, "Anirudh"  wrote:

Hi,

We can have a separate discussion on whether this was a friendly way to
bring this up or not,
but I don't see why we shouldn't roll back, share design on dev, fix the
bug and add performance benchmarking results and call for reviews on
a new PR. This seems to be a big change which was introduced and I have
seen Eric himself rolling back PRs
for big changes which happen to have a regression or insufficient tests. To
quote Eric from here
https://github.com/apache/incubator-mxnet/pull/8010 : "Roll
back is always better than fix forward."
I agree with Marco that we should abide by the rules which we set for other
contributors.
If the argument is that users depend on the change since it has been
introduced a few days ago, then the assumption with depending on the master
is always that it is bleeding edge and things can break.

Anirudh

On Fri, Jun 15, 2018 at 3:10 PM, Mu Li  wrote:

> Hi Marco,
>
> You really want to bring it into Amazon internal planning meeting. I have
> been requesting to focus on fixing bugs for several weeks, instead of
> adding new features. But I didn't get a concrete time when it will happen.
>
> Best
> Mu
>
> On Fri, Jun 15, 2018 at 3:03 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
> > CI doesn't fail for no reason but because some people prefer to push new
> > features than to get our codebase actually stable. We currently have 51
> [1]
> > flaky tests and I have only seen a few people (thanks Sheng, Alex and
> > Pedro) work on the problem. So instead of complaining, take part and 
help
> > improving the situation.
> >
> > The CCache/EFS failure lasted for 12 hours and was an error - these
> things
> > happen when you run a service. This is not a blame-game.
> >
> > -Marco
> >
> > [1]:
> > https://github.com/apache/incubator-mxnet/issues?q=is%
> > 3Aopen+is%3Aissue+label%3AFlaky
> >
> > On Fri, Jun 15, 2018 at 2:55 PM Eric Xie  wrote:
> >
> > > Hi Marco de Abreu,
> > >
> > > CI has been totally broken recently. It randomly fails for no good
> reason
> > > more often than it passes. For example the ccache/efs failure has been
> > > really annoying.
> > >
> > > Looks like there has been many changes to Jenkins and Docker lately. 
Do
> > > you think we should revert all of the recent changes to get a stable 
CI
> > or
> > > do you think someone should find a fix for the bugs?
> > >
> > > Thanks,
> > > Eric
> > >
> > > On 2018/06/15 21:21:50, Marco de Abreu  > INVALID>
> > > wrote:
> > > > We revert a PR because it should not have been merged in the first
> > place.
> > > > So far, I have been ignoring the fact that our committers are
> > constantly
> > > > breaking our own rules (which we expect contributors to follow). But
> > > since
> > > > this caused an impact twice (1.2 breaking change about model
> > > import/export
> > > > as well as this regression), I'm now being more strict and enforcing
> > > them.
> > > >
> > > > I could've also made a script that prevents any PR from being
> > > self-merged,
> > > > but I thought our committers are responsible enough to follow our 
own
> > > rules
> > > > without systems actually enforcing them. I won't waste my time
> working
> > on
> > > > that script, but from now on I will revert every single PR (except
> > > > emergency 

Re: About Becoming a Committer

[Hen]

That wasn't what I was trying to say (I'll try again - tis late and I'm
sure I'm speaking poorly :) ).

It says:

"When it comes to code contributions, quality is more important than
quantity. While all contributions are welcome and highly appreciated,
certain guidelines will be applied when it comes to committer nominations,
e.g. clean, documented and maintainable code, including unit tests if
applicable. Updating license text or fixing indentation in hundreds of
source files for instance is case of quantity trumping quality. "

If someone is updating licensing text, or fixing indentation, then that is
great. That's as good as someone who wrote a lump of clean, documented and
maintainable code with unit tests. The important part isn't the patch, it's
how much back and forth there had to be to get the patch to the point where
it could be merged.

My concern, and I feel the language on the page reflects this, is that one
commit is rated higher than a different commit with regards to showing
commitment. That's wrong imo. All commits are equal (as are any other
actions for the project, such as answering a question, improving wiki,
maintaining CI, helping people on Slack). Becoming a committer is about the
trust built up by the committers not having to modify the action (PR,
proposed-answer, proposed-wiki-change etc).

Hen

On Fri, Jun 15, 2018 at 12:26 AM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> Hen,
>
> As you stated, it's of significance of how much a PR has to be changed as a
> result of a review. I think this is what this project defines as quality.
>
> If people submit a bunch of PRs and we reviewers spend a lot of time on
> every single one of them to give the contributors advice about how to do it
> the right way, then that's a great contribution but doesn't really show
> that the person is either up par with the standards of the project or
> understood the design principles. In both cases they added value to the
> project, but the bar would have been lowered if the reviewers didn't
> intercept. Of course, there is always something people will have to
> criticize as part of the review and that's natural. But what you are
> describing here is basically that we should make people committers because
> of the amount of value they added through the code.
>
> While that's a good way to look at it in general, it doesn't consider
> important aspects: how much of this value has been added by the reviewer?
> And what happens if that person starts merging  other PRs. If a person who
> is not up par with the standards of the project is granted permission to
> merge pull requests and they merge them prematurely because they don't know
> that things are wrong, then this is harming the project in the long term.
> If more and more people with lower standards are granted permissions, we
> will enter a downwards spiral.
>
> That's why I have to disagree that it's not about how often a PR has been
> merged but rather about how often it has to be altered as result of our
> reviews.
>
> -Marco
>
> Hen  schrieb am Fr., 15. Juni 2018, 00:00:
>
> > On the 'Becoming+a+Committer' guidelines, I dislike this phrase:
> >
> > "When it comes to code contributions, quality is more important than
> > quantity"
> >
> > There is only one 'quality' measurement, and that is "was the code
> merged".
> > If someone makes 10 different contributions and they were all horrible
> and
> > never merged (or the merger had to write a ton of fixes/tests/additions)
> > then yes, that's a pretty bad sign.
> >
> > If the code was merged; I don't care if it's stunning code or an inspired
> > design. It was merged. This isn't a technical promotion process, this is
> > about whether the individual has shown the commitment to be extended the
> > trust to manage commits.
> >
> > So; -1 to quality being more important than quantity. It's not.
> >
> > Hen
> >
> >
> >
> > On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha  wrote:
> >
> > > Hi,
> > >
> > > There have been a couple of offline inquiries from contributors about
> > > becoming a committer. From those inquiries, it seems that there’s
> > confusion
> > > in our community about how to become a committer, so I’d like to take
> > this
> > > opportunity to clarify.
> > >
> > > The guideline about becoming a committer can be found at
> > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> .
> > > The
> > > gist of the guideline is that, like any other Apache project, MXNet
> > > committers are invited by existing committers based on merit. The
> > existing
> > > committers look for sustained, high quality contribution and community
> > > involvement among project contributors. When a candidate is spotted,
> this
> > > contributor will be nominated and voted among PMC members, and if all
> > goes
> > > well, this contributor will receive an invitation to join as a
> committer
> > > and PMC member.
> > >
> > > Note that such discussion and decision happens in private 

Re: About Becoming a Committer

[Marco de Abreu]

Totally agree, thanks for elaborating!

Hen  schrieb am Fr., 15. Juni 2018, 00:44:

> That wasn't what I was trying to say (I'll try again - tis late and I'm
> sure I'm speaking poorly :) ).
>
> It says:
>
> "When it comes to code contributions, quality is more important than
> quantity. While all contributions are welcome and highly appreciated,
> certain guidelines will be applied when it comes to committer nominations,
> e.g. clean, documented and maintainable code, including unit tests if
> applicable. Updating license text or fixing indentation in hundreds of
> source files for instance is case of quantity trumping quality. "
>
> If someone is updating licensing text, or fixing indentation, then that is
> great. That's as good as someone who wrote a lump of clean, documented and
> maintainable code with unit tests. The important part isn't the patch, it's
> how much back and forth there had to be to get the patch to the point where
> it could be merged.
>
> My concern, and I feel the language on the page reflects this, is that one
> commit is rated higher than a different commit with regards to showing
> commitment. That's wrong imo. All commits are equal (as are any other
> actions for the project, such as answering a question, improving wiki,
> maintaining CI, helping people on Slack). Becoming a committer is about the
> trust built up by the committers not having to modify the action (PR,
> proposed-answer, proposed-wiki-change etc).
>
> Hen
>
> On Fri, Jun 15, 2018 at 12:26 AM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
> > Hen,
> >
> > As you stated, it's of significance of how much a PR has to be changed
> as a
> > result of a review. I think this is what this project defines as quality.
> >
> > If people submit a bunch of PRs and we reviewers spend a lot of time on
> > every single one of them to give the contributors advice about how to do
> it
> > the right way, then that's a great contribution but doesn't really show
> > that the person is either up par with the standards of the project or
> > understood the design principles. In both cases they added value to the
> > project, but the bar would have been lowered if the reviewers didn't
> > intercept. Of course, there is always something people will have to
> > criticize as part of the review and that's natural. But what you are
> > describing here is basically that we should make people committers
> because
> > of the amount of value they added through the code.
> >
> > While that's a good way to look at it in general, it doesn't consider
> > important aspects: how much of this value has been added by the reviewer?
> > And what happens if that person starts merging  other PRs. If a person
> who
> > is not up par with the standards of the project is granted permission to
> > merge pull requests and they merge them prematurely because they don't
> know
> > that things are wrong, then this is harming the project in the long term.
> > If more and more people with lower standards are granted permissions, we
> > will enter a downwards spiral.
> >
> > That's why I have to disagree that it's not about how often a PR has been
> > merged but rather about how often it has to be altered as result of our
> > reviews.
> >
> > -Marco
> >
> > Hen  schrieb am Fr., 15. Juni 2018, 00:00:
> >
> > > On the 'Becoming+a+Committer' guidelines, I dislike this phrase:
> > >
> > > "When it comes to code contributions, quality is more important than
> > > quantity"
> > >
> > > There is only one 'quality' measurement, and that is "was the code
> > merged".
> > > If someone makes 10 different contributions and they were all horrible
> > and
> > > never merged (or the merger had to write a ton of
> fixes/tests/additions)
> > > then yes, that's a pretty bad sign.
> > >
> > > If the code was merged; I don't care if it's stunning code or an
> inspired
> > > design. It was merged. This isn't a technical promotion process, this
> is
> > > about whether the individual has shown the commitment to be extended
> the
> > > trust to manage commits.
> > >
> > > So; -1 to quality being more important than quantity. It's not.
> > >
> > > Hen
> > >
> > >
> > >
> > > On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha  wrote:
> > >
> > > > Hi,
> > > >
> > > > There have been a couple of offline inquiries from contributors about
> > > > becoming a committer. From those inquiries, it seems that there’s
> > > confusion
> > > > in our community about how to become a committer, so I’d like to take
> > > this
> > > > opportunity to clarify.
> > > >
> > > > The guideline about becoming a committer can be found at
> > > >
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > .
> > > > The
> > > > gist of the guideline is that, like any other Apache project, MXNet
> > > > committers are invited by existing committers based on merit. The
> > > existing
> > > > committers look for sustained, high quality contribution and
> community
> > > > involvement among 

Re: About Becoming a Committer

[Hen]

On the 'Becoming+a+Committer' guidelines, I dislike this phrase:

"When it comes to code contributions, quality is more important than
quantity"

There is only one 'quality' measurement, and that is "was the code merged".
If someone makes 10 different contributions and they were all horrible and
never merged (or the merger had to write a ton of fixes/tests/additions)
then yes, that's a pretty bad sign.

If the code was merged; I don't care if it's stunning code or an inspired
design. It was merged. This isn't a technical promotion process, this is
about whether the individual has shown the commitment to be extended the
trust to manage commits.

So; -1 to quality being more important than quantity. It's not.

Hen



On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha  wrote:

> Hi,
>
> There have been a couple of offline inquiries from contributors about
> becoming a committer. From those inquiries, it seems that there’s confusion
> in our community about how to become a committer, so I’d like to take this
> opportunity to clarify.
>
> The guideline about becoming a committer can be found at
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer.
> The
> gist of the guideline is that, like any other Apache project, MXNet
> committers are invited by existing committers based on merit. The existing
> committers look for sustained, high quality contribution and community
> involvement among project contributors. When a candidate is spotted, this
> contributor will be nominated and voted among PMC members, and if all goes
> well, this contributor will receive an invitation to join as a committer
> and PMC member.
>
> Note that such discussion and decision happens in private among existing
> PMC members and mentors through consensus, and information regarding what
> happened in this process will always remain private, so as to rid the
> influence of different interest groups. PMC members will not ask
> contributors for committer application, nor will they accept one. Except
> the aforementioned PMC members consensus process, any other process by any
> organization under any circumstances will not be recognized.
>
> I hope that you find the above clarification helpful. If you have further
> question on this topic feel free to ask.
>
> Sheng
>

Re: About Becoming a Committer

[Marco de Abreu]

Hen,

As you stated, it's of significance of how much a PR has to be changed as a
result of a review. I think this is what this project defines as quality.

If people submit a bunch of PRs and we reviewers spend a lot of time on
every single one of them to give the contributors advice about how to do it
the right way, then that's a great contribution but doesn't really show
that the person is either up par with the standards of the project or
understood the design principles. In both cases they added value to the
project, but the bar would have been lowered if the reviewers didn't
intercept. Of course, there is always something people will have to
criticize as part of the review and that's natural. But what you are
describing here is basically that we should make people committers because
of the amount of value they added through the code.

While that's a good way to look at it in general, it doesn't consider
important aspects: how much of this value has been added by the reviewer?
And what happens if that person starts merging  other PRs. If a person who
is not up par with the standards of the project is granted permission to
merge pull requests and they merge them prematurely because they don't know
that things are wrong, then this is harming the project in the long term.
If more and more people with lower standards are granted permissions, we
will enter a downwards spiral.

That's why I have to disagree that it's not about how often a PR has been
merged but rather about how often it has to be altered as result of our
reviews.

-Marco

Hen  schrieb am Fr., 15. Juni 2018, 00:00:

> On the 'Becoming+a+Committer' guidelines, I dislike this phrase:
>
> "When it comes to code contributions, quality is more important than
> quantity"
>
> There is only one 'quality' measurement, and that is "was the code merged".
> If someone makes 10 different contributions and they were all horrible and
> never merged (or the merger had to write a ton of fixes/tests/additions)
> then yes, that's a pretty bad sign.
>
> If the code was merged; I don't care if it's stunning code or an inspired
> design. It was merged. This isn't a technical promotion process, this is
> about whether the individual has shown the commitment to be extended the
> trust to manage commits.
>
> So; -1 to quality being more important than quantity. It's not.
>
> Hen
>
>
>
> On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha  wrote:
>
> > Hi,
> >
> > There have been a couple of offline inquiries from contributors about
> > becoming a committer. From those inquiries, it seems that there’s
> confusion
> > in our community about how to become a committer, so I’d like to take
> this
> > opportunity to clarify.
> >
> > The guideline about becoming a committer can be found at
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer.
> > The
> > gist of the guideline is that, like any other Apache project, MXNet
> > committers are invited by existing committers based on merit. The
> existing
> > committers look for sustained, high quality contribution and community
> > involvement among project contributors. When a candidate is spotted, this
> > contributor will be nominated and voted among PMC members, and if all
> goes
> > well, this contributor will receive an invitation to join as a committer
> > and PMC member.
> >
> > Note that such discussion and decision happens in private among existing
> > PMC members and mentors through consensus, and information regarding what
> > happened in this process will always remain private, so as to rid the
> > influence of different interest groups. PMC members will not ask
> > contributors for committer application, nor will they accept one. Except
> > the aforementioned PMC members consensus process, any other process by
> any
> > organization under any circumstances will not be recognized.
> >
> > I hope that you find the above clarification helpful. If you have further
> > question on this topic feel free to ask.
> >
> > Sheng
> >
>

Re: GitHub Label Bot Design

[Hen]

Thanks Cathy.

As a high level concept, scripts the project depends on should be committed
to the project (I say this more as a note for everyone rather than calling
you out specifically :) ).

Hen

On Thu, Jun 14, 2018 at 9:31 PM, Yuelin Zhang 
wrote:

> Hi Hen,
>
> I am not using probot. Now my bot code is running in a AWS lambda function.
> I will ask my manager and my mentors about where will the bot code be
> committed.
>
>
> Thanks,
> Cathy
>
> On Wed, Jun 13, 2018 at 8:09 AM, Hen  wrote:
>
> > Where will the bot code be committed?
> >
> > Are you using probot?
> >
> > On Tue, Jun 12, 2018 at 2:21 PM Marco de Abreu <
> > marco.g.ab...@googlemail.com>
> > wrote:
> >
> > > Hello Cathy,
> > > that's a great proposal. Thank you!
> > >
> > > A few comments from my side:
> > > - Good idea with the alias. We should have a special email-list for
> > > automated reports to prevent spamming dev@.
> > > - "Create weekly email to internal team members:" -> email-list
> > > - "Part II - Label Bot - Amazon cloudwatch event (a) will trigger
> lambda
> > > function(a) 9am every Monday. " -> Why don't we try to classify them
> > ASAP?
> > > - "This bot should have restricted permissions to avoid unexpected
> > > operations." -> AFAIK, Apache does not allow bot accounts and we have
> to
> > > use a committers credentials instead. This is not a big issue since we
> > > already do this, but just to keep that in mind.
> > >
> > > Best regards,
> > > Marco
> > >
> > > On Tue, Jun 12, 2018 at 1:07 PM Yuelin Zhang <
> zhangyuelinch...@gmail.com
> > >
> > > wrote:
> > >
> > > > Sorry for the messed up url format.
> > > > Please forward to this link: https://tinyurl.com/mxnetbot
> > > >
> > > >
> > > > Thanks,
> > > > Cathy
> > > >
> > > >
> > > > On Tue, Jun 12, 2018 at 10:20 AM, Yuelin Zhang <
> > > zhangyuelinch...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Currently there are many issues on Incubator-MXNet
> > > > >  repo, labeling issues
> > can
> > > > > drive attention of  contributors to specific areas. Right now,
> issues
> > > are
> > > > > all manually labelled, which is time consuming.  And every time
> > > > maintainers
> > > > > need to @ a committer to add labels.
> > > > > I am working on this label bot to automate/simplify this labeling
> > issue
> > > > > process and send weekly report to maintainers. Design proposal is
> on
> > > > cwiki:
> > > > > https://cwiki.apache.org/confluence/display/MXNET/Deep+Learn
> > > > > ing+Based+GitHub+Label+Bot
> > > > >
> > > > > Please feel free to let me know if you have
> suggestions/requirements/
> > > > > expectations.
> > > > >
> > > > > Thanks,
> > > > > Cathy
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: About Becoming a Committer

[Hen]

On Tue, Jun 12, 2018 at 10:54 PM, Pedro Larroy  wrote:

> * I personally don't like the idea that comittership status is decided in a
> closed mail list. This is not the transparency level that I would expect in
> an open source project. I'm happy to receive feedback from others that
> might be opposed to my application for committer to know what things could
> be improved to get there. I have been doing a plethora of contributions to
> the project over a year including ARM support, Android and CI, obviously
> some of this work together with my team at Amazon (@lebeg,
> @KellenSunderland, @marcoabreu). I don't have visibility on how much longer
> one has to wait, or what needs to be improved to get there.
>

I agree in principle (which means I'm going to disagree, right? :) ).

Ideally discussion about extending community trust would be made in public,
however for many of us having that discussion in public is an uncomfortable
act. A private channel for feedback is not about hiding information from
the subject, but about creating a safe place in which someone can provide
that feedback.

I think you have a very valid and, slightly to the side, point of it not
being clear what steps are needed/remaining to become a committer; which is
affected by the podling pmc still seeking consensus on how they view it.


>
> * My team is on-call for CI / CD which is also sponsored by us. To fix
> problems promptly we would need write permissions to the repository. This
> would normal in any other project, be open source or corporate. I think
> it's not effective to be on-call when you can't submit critical fixes and
> wait days for a CR. Basically I think everyone responsible or involved in
> CI should have access rights. As you know, testing our project is a
> challenging task for reasons discussed before.
>

Personally I don't care. If the committers aren't handling the CI/CD then
it's not important to the project. It's EXCELLENT that you and your team
are contributing your time to run CI/CD for the project, but the notion
that an open source project requires an on-call CI/CD is, in my opinion,
the project having its priorities skewed. However, that said, I agree that
if the project is unable to survive without the CI/CD, then it sounds far
more important than whatever code is being committed and shows more
commitment to the project than the creator of a piece of code.

I'm pretty sure my opinion that the CI/CD is not crucial is heretical for
this community. I suspect that if I said we should turn it off for a week
there would be a wailing and gnashing of teeth from every corner of the
mailing list. Given that, I think you earn more 'become committer points'
by maintaining that CI/CD than someone does by coding.


> Please committers and mentors, provide a solution that allows us to work
> more effectively and move the project forward faster, as is vital to make
> it easier to contribute so we can attract more users.
>

+1. The podling pmc needs to find consensus on the become-committer stage.

Hen