Re: New Apache MXNet logo idea

[Henri Yandell]

Love :)

Lots of good connections here. Nice feather style/colour in the bunny's
silhouette, nice "magic" overlay for connection to Clarke's third law (any
sufficiently deep learning is indistinguishable from magic), great name
connection to 'mx' and the Chinese zodiac may, if appropriate, speak well
to MXNet's popularity in China (looking to those from/more versed in
China's culture for help there).

I do note that the zodiac rabbit's lucky colours are Apache's colours in
the feather.

Anyway - love it :)

Hen

On Thu, Sep 28, 2017 at 12:52 Seb Kiureghian  wrote:

>
> https://user-images.githubusercontent.com/591887/30987393-ba66e610-a44b-11e7-8226-da1711dcbdc5.jpg
>
>
>
> On Thu, Sep 28, 2017 at 12:38 PM, Madan Jampani 
> wrote:
>
> > Is there a picture of Max?
> >
> > On Thu, Sep 28, 2017 at 12:17 PM, Seb Kiureghian 
> > wrote:
> >
> >> Hi all,
> >>
> >> I have a new idea for a logo that I'd like to propose.
> >>
> >> The rabbit (I call him Max) is blazingly fast, like MXNet, but also
> >> friendly and approachable, like the Gluon interface.
> >>
> >> Do you all like it?
> >>
> >> Seb
> >>
> >
> >
>

Re: New Apache MXNet logo idea

[Simon Corston-Oliver]

Very attractive logo. Is it a depiction of pulling a rabbit out of a hat
, i.e. doing
things by magic?

On Thu, Sep 28, 2017 at 12:52 PM, Seb Kiureghian  wrote:

> https://user-images.githubusercontent.com/591887/
> 30987393-ba66e610-a44b-11e7-8226-da1711dcbdc5.jpg
>
>
>
> On Thu, Sep 28, 2017 at 12:38 PM, Madan Jampani 
> wrote:
>
> > Is there a picture of Max?
> >
> > On Thu, Sep 28, 2017 at 12:17 PM, Seb Kiureghian 
> > wrote:
> >
> >> Hi all,
> >>
> >> I have a new idea for a logo that I'd like to propose.
> >>
> >> The rabbit (I call him Max) is blazingly fast, like MXNet, but also
> >> friendly and approachable, like the Gluon interface.
> >>
> >> Do you all like it?
> >>
> >> Seb
> >>
> >
> >
>

Re: New Apache MXNet logo idea

[Seb Kiureghian]

https://user-images.githubusercontent.com/591887/30987393-ba66e610-a44b-11e7-8226-da1711dcbdc5.jpg



On Thu, Sep 28, 2017 at 12:38 PM, Madan Jampani 
wrote:

> Is there a picture of Max?
>
> On Thu, Sep 28, 2017 at 12:17 PM, Seb Kiureghian 
> wrote:
>
>> Hi all,
>>
>> I have a new idea for a logo that I'd like to propose.
>>
>> The rabbit (I call him Max) is blazingly fast, like MXNet, but also
>> friendly and approachable, like the Gluon interface.
>>
>> Do you all like it?
>>
>> Seb
>>
>
>

Re: New Apache MXNet logo idea

[Simon Corston-Oliver]

There are many other associations that people might have with a rabbit
depending on their cultural and linguistic background, not all of them
things we would want to have associated with MXNet.

Free-associating as an English speaker: rabbits are associated with
fertility (Easter), promiscuity ("&*&^ like rabbits"), good luck ("white
rabbits", rabbit foot necklace amulets), disease (see *Myxomatosis), *pests
(e.g. New Zealand
),
going astray/crazy ("down the rabbit hole")*.*

It's one of the animals in the Chinese Zodiac cycle with strong
associations.

On Thu, Sep 28, 2017 at 12:38 PM, Madan Jampani 
wrote:

> Is there a picture of Max?
>
> On Thu, Sep 28, 2017 at 12:17 PM, Seb Kiureghian 
> wrote:
>
> > Hi all,
> >
> > I have a new idea for a logo that I'd like to propose.
> >
> > The rabbit (I call him Max) is blazingly fast, like MXNet, but also
> > friendly and approachable, like the Gluon interface.
> >
> > Do you all like it?
> >
> > Seb
> >
>

Re: New Apache MXNet logo idea

[Madan Jampani]

Is there a picture of Max?

On Thu, Sep 28, 2017 at 12:17 PM, Seb Kiureghian  wrote:

> Hi all,
>
> I have a new idea for a logo that I'd like to propose.
>
> The rabbit (I call him Max) is blazingly fast, like MXNet, but also
> friendly and approachable, like the Gluon interface.
>
> Do you all like it?
>
> Seb
>

Re: MXNet Slack channel

[Zha, Sheng]

Invited.

Best regards,
-sz

On 9/28/17, 12:31 PM, "Jin Sun"  wrote:

Please give me an invite as well.
Thanks,
Jin

2017-09-28 12:14 GMT-07:00 Jean K :

> Hi,
> I would like to join the MXNet Slack Channel.
> Best,
> Jean
>



-- 

*Jin Sun*
Software Engineer II at Uber
M.Eng. in ECE at Carnegie Mellon University

Re: MXNet Slack channel

[Jin Sun]

Please give me an invite as well.
Thanks,
Jin

2017-09-28 12:14 GMT-07:00 Jean K :

> Hi,
> I would like to join the MXNet Slack Channel.
> Best,
> Jean
>



-- 

*Jin Sun*
Software Engineer II at Uber
M.Eng. in ECE at Carnegie Mellon University

New Apache MXNet logo idea

[Seb Kiureghian]

Hi all,

I have a new idea for a logo that I'd like to propose.

The rabbit (I call him Max) is blazingly fast, like MXNet, but also
friendly and approachable, like the Gluon interface.

Do you all like it?

Seb

Re: Apache MXNet build failures are mostly valid - verify before merge

[Zha, Sheng]

+1 on protected branch.

Best regards,
-sz

On 9/28/17, 11:48 AM, "Kumar, Gautam"  wrote:

Hi Guys, 

 Let’s focus on specific issue here. 

Marking the master branch protected which involves “Only merge if checks 
has passed, and yes it will run the complete build”. 

We can’t afford to degrade the quality and keep debugging the build failure 
forever. If it’s slow down the development at the cost of quality I will vote 
for the quality. 
We can work on improving the infrastructure to improve the overall speed.  
If you have any specific concerns on availability of Jenkins please point out. 

-Gautam 


On 9/28/17, 11:38 AM, "Chris Olivier"  wrote:

-1000 on that. :)

On Thu, Sep 28, 2017 at 11:33 AM Naveen Swamy  
wrote:

> PR->Sanity test/Linux build/test->reviewer/committer approves the
> change->Comment "Build Now" (Or trigger on at least one approval from 
a
> committer other than author)->*Full build-*>*passes build*->Enable 
Merge
>
> Let us take this particular topic to a separate thread or discuss 
offline
> if further clarification is needed.
>
> On Thu, Sep 28, 2017 at 11:24 AM, Chris Olivier 

> wrote:
>
> > I understand the proposal.  How to trigger a build in that case?
> >
> >
> > On Thu, Sep 28, 2017 at 10:54 AM Madan Jampani 

> > wrote:
> >
> > > Chris,
> > > I don't think Naveen is suggesting that a merge happen without 
full
> > > verification i.e. all tests across all platforms pass.
> > > If a PR has some back and forth and results in multiple revisions
> (which
> > is
> > > arguably more common than a random unit test failing), we simply 
delay
> > full
> > > verification until the owner/reviewer have settled on a mutually
> > acceptable
> > > state.
> > >
> > > On Thu, Sep 28, 2017 at 10:25 AM, Chris Olivier 
 >
> > > wrote:
> > >
> > > > -1 for running only partial tests.  Most failing unit tests 
that get
> > > > through fail only for certain platforms/configurations.  I 
personally
> > > > prefer to be assured the build and test is good before merge.  
Most
> PR
> > > > merges aren't in a huge hurry.
> > > >
> > > > On Thu, Sep 28, 2017 at 9:54 AM, Naveen Swamy 

> > > wrote:
> > > >
> > > > > +1 to make it protected. Here is what I am thinking for PR 
builds
> > > > > on a PR run Sanity Tests + build/test one platform->committer
> reviews
> > > the
> > > > > code and issues "Build Now", a full build is run->Github 
checks
> that
> > > the
> > > > > full build checks succeed before it can be merged.
> > > > >
> > > > > I agree with Madan that PR should be approved by one another
> > committer.
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Sep 28, 2017 at 9:37 AM, Madan Jampani <
> > > madan.jamp...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > At a minimum I'd like to see the following two happen:
> > > > > > - Option to merge is disabled until all required checks 
pass.
> > > > > > - Code is reviewed and given +1 by at least one other 
committer
> (no
> > > > self
> > > > > > review).
> > > > > >
> > > > > > On Wed, Sep 27, 2017 at 11:15 PM, Gautam 

> > > wrote:
> > > > > >
> > > > > > > Hi Chris,
> > > > > > >
> > > > > > >   Here  > branches/
> > > >
> > > > is
> > > > > > > user
> > > > > > > document on semantics of protected branch.
> > > > > > > In short when a branch is protected following applies to 
that
> > > branch.
> > > > > > >
> > > > > > >- Can't be force pushed
> > > > > > >- Can't be deleted
> > > > > > >- Can't have changes merged into it until required 
status
> > checks
> > > > > > > > status-checks>
> > > > > pass
> > > > > > >- Can't have changes merged into it until required 
reviews
> are
> > > > > > approved
> > > > > > > > > > > > > request-with-required-reviews>
> > > > > > >- Can't be edited or have files uploaded to it from 
the web
> > > > > > >- Can't have changes merged into it until changes to 
files
> > that
> > > > > > > have a designated
> > > > > > >code owner 

MXNet Slack channel

[Jean K]

Hi,
I would like to join the MXNet Slack Channel.
Best,
Jean

Re: Apache MXNet build failures are mostly valid - verify before merge

[Kumar, Gautam]

Hi Guys, 

 Let’s focus on specific issue here. 

Marking the master branch protected which involves “Only merge if checks has 
passed, and yes it will run the complete build”. 

We can’t afford to degrade the quality and keep debugging the build failure 
forever. If it’s slow down the development at the cost of quality I will vote 
for the quality. 
We can work on improving the infrastructure to improve the overall speed.  If 
you have any specific concerns on availability of Jenkins please point out. 

-Gautam 


On 9/28/17, 11:38 AM, "Chris Olivier"  wrote:

-1000 on that. :)

On Thu, Sep 28, 2017 at 11:33 AM Naveen Swamy  wrote:

> PR->Sanity test/Linux build/test->reviewer/committer approves the
> change->Comment "Build Now" (Or trigger on at least one approval from a
> committer other than author)->*Full build-*>*passes build*->Enable Merge
>
> Let us take this particular topic to a separate thread or discuss offline
> if further clarification is needed.
>
> On Thu, Sep 28, 2017 at 11:24 AM, Chris Olivier 
> wrote:
>
> > I understand the proposal.  How to trigger a build in that case?
> >
> >
> > On Thu, Sep 28, 2017 at 10:54 AM Madan Jampani 
> > wrote:
> >
> > > Chris,
> > > I don't think Naveen is suggesting that a merge happen without full
> > > verification i.e. all tests across all platforms pass.
> > > If a PR has some back and forth and results in multiple revisions
> (which
> > is
> > > arguably more common than a random unit test failing), we simply delay
> > full
> > > verification until the owner/reviewer have settled on a mutually
> > acceptable
> > > state.
> > >
> > > On Thu, Sep 28, 2017 at 10:25 AM, Chris Olivier  >
> > > wrote:
> > >
> > > > -1 for running only partial tests.  Most failing unit tests that get
> > > > through fail only for certain platforms/configurations.  I 
personally
> > > > prefer to be assured the build and test is good before merge.  Most
> PR
> > > > merges aren't in a huge hurry.
> > > >
> > > > On Thu, Sep 28, 2017 at 9:54 AM, Naveen Swamy 
> > > wrote:
> > > >
> > > > > +1 to make it protected. Here is what I am thinking for PR builds
> > > > > on a PR run Sanity Tests + build/test one platform->committer
> reviews
> > > the
> > > > > code and issues "Build Now", a full build is run->Github checks
> that
> > > the
> > > > > full build checks succeed before it can be merged.
> > > > >
> > > > > I agree with Madan that PR should be approved by one another
> > committer.
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Sep 28, 2017 at 9:37 AM, Madan Jampani <
> > > madan.jamp...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > At a minimum I'd like to see the following two happen:
> > > > > > - Option to merge is disabled until all required checks pass.
> > > > > > - Code is reviewed and given +1 by at least one other committer
> (no
> > > > self
> > > > > > review).
> > > > > >
> > > > > > On Wed, Sep 27, 2017 at 11:15 PM, Gautam 
> > > wrote:
> > > > > >
> > > > > > > Hi Chris,
> > > > > > >
> > > > > > >   Here  > branches/
> > > >
> > > > is
> > > > > > > user
> > > > > > > document on semantics of protected branch.
> > > > > > > In short when a branch is protected following applies to that
> > > branch.
> > > > > > >
> > > > > > >- Can't be force pushed
> > > > > > >- Can't be deleted
> > > > > > >- Can't have changes merged into it until required status
> > checks
> > > > > > > > status-checks>
> > > > > pass
> > > > > > >- Can't have changes merged into it until required reviews
> are
> > > > > > approved
> > > > > > > > > > > > > request-with-required-reviews>
> > > > > > >- Can't be edited or have files uploaded to it from the web
> > > > > > >- Can't have changes merged into it until changes to files
> > that
> > > > > > > have a designated
> > > > > > >code owner  > articles/about-codeowners/>
> > > > > have
> > > > > > >been approved by that owner
> > > > > > >
> > > > > > >  I am sure many of us might not want to have all these but we
> can
> > > > > debate
> > > > > > on
> > > > > > > it. My main motive was to "*Can't have changes merged into it
> > until
> > > > > > > required status checks pass*"
> > > > > > >
> > > > > > >
> > > > > > > -Gautam
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Sep 27, 2017 at 11:

Re: PR builds are currently failing due to a known issue

[Meghna Baijal]

Naveen, 
I have reverted the changes and created a new PR. Can someone please merge this 
quickly - https://github.com/apache/incubator-mxnet/pull/8078 


Thanks,
Meghna Baijal
> On Sep 28, 2017, at 10:32 AM, Daniel Pono Takamori  wrote:
> 
> Unfortunately we won't be able to enable all the Groovy methods for
> security reasons.  Fortunately the Beam team has found some work
> arounds for this so I'm cc'ing them to connect you to figure out how
> to get around this issue.
> 
> Jason, if you could point the MXNet folks to your builds repo so they
> could take a look and ask questions, that would be great!
> 
> On Thu, Sep 28, 2017 at 10:59 AM, Naveen Swamy  wrote:
>> Please revert this change until Apache Infra approve all the required
>> scripts? I don't think we should let the PR builds continue to fail this
>> long.
>> 
>> On Wed, Sep 27, 2017 at 3:57 PM, Meghna Baijal 
>> wrote:
>> 
>>> Hi All,
>>> This is just to let everyone know that PR #8034 is breaking the Apache
>>> MXNet PR builds for the moment. The master branch is not affected by this.
>>> 
>>> This PR makes changes to the Jenkinsfile and some script approvals are
>>> required from the Apache infra team. I have opened a JIRA ticket for the
>>> same -https://issues.apache.org/jira/browse/INFRA-15176 <
>>> https://issues.apache.org/jira/browse/INFRA-15176> and we are in the
>>> process of resolving it.
>>> 
>>> I will update this thread once the issue is fixed.
>>> 
>>> Thanks,
>>> Meghna Baijal
>>> 
>>> 

Re: Apache MXNet build failures are mostly valid - verify before merge

[Chris Olivier]

-1000 on that. :)

On Thu, Sep 28, 2017 at 11:33 AM Naveen Swamy  wrote:

> PR->Sanity test/Linux build/test->reviewer/committer approves the
> change->Comment "Build Now" (Or trigger on at least one approval from a
> committer other than author)->*Full build-*>*passes build*->Enable Merge
>
> Let us take this particular topic to a separate thread or discuss offline
> if further clarification is needed.
>
> On Thu, Sep 28, 2017 at 11:24 AM, Chris Olivier 
> wrote:
>
> > I understand the proposal.  How to trigger a build in that case?
> >
> >
> > On Thu, Sep 28, 2017 at 10:54 AM Madan Jampani 
> > wrote:
> >
> > > Chris,
> > > I don't think Naveen is suggesting that a merge happen without full
> > > verification i.e. all tests across all platforms pass.
> > > If a PR has some back and forth and results in multiple revisions
> (which
> > is
> > > arguably more common than a random unit test failing), we simply delay
> > full
> > > verification until the owner/reviewer have settled on a mutually
> > acceptable
> > > state.
> > >
> > > On Thu, Sep 28, 2017 at 10:25 AM, Chris Olivier  >
> > > wrote:
> > >
> > > > -1 for running only partial tests.  Most failing unit tests that get
> > > > through fail only for certain platforms/configurations.  I personally
> > > > prefer to be assured the build and test is good before merge.  Most
> PR
> > > > merges aren't in a huge hurry.
> > > >
> > > > On Thu, Sep 28, 2017 at 9:54 AM, Naveen Swamy 
> > > wrote:
> > > >
> > > > > +1 to make it protected. Here is what I am thinking for PR builds
> > > > > on a PR run Sanity Tests + build/test one platform->committer
> reviews
> > > the
> > > > > code and issues "Build Now", a full build is run->Github checks
> that
> > > the
> > > > > full build checks succeed before it can be merged.
> > > > >
> > > > > I agree with Madan that PR should be approved by one another
> > committer.
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Sep 28, 2017 at 9:37 AM, Madan Jampani <
> > > madan.jamp...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > At a minimum I'd like to see the following two happen:
> > > > > > - Option to merge is disabled until all required checks pass.
> > > > > > - Code is reviewed and given +1 by at least one other committer
> (no
> > > > self
> > > > > > review).
> > > > > >
> > > > > > On Wed, Sep 27, 2017 at 11:15 PM, Gautam 
> > > wrote:
> > > > > >
> > > > > > > Hi Chris,
> > > > > > >
> > > > > > >   Here  > branches/
> > > >
> > > > is
> > > > > > > user
> > > > > > > document on semantics of protected branch.
> > > > > > > In short when a branch is protected following applies to that
> > > branch.
> > > > > > >
> > > > > > >- Can't be force pushed
> > > > > > >- Can't be deleted
> > > > > > >- Can't have changes merged into it until required status
> > checks
> > > > > > > > status-checks>
> > > > > pass
> > > > > > >- Can't have changes merged into it until required reviews
> are
> > > > > > approved
> > > > > > > > > > > > > request-with-required-reviews>
> > > > > > >- Can't be edited or have files uploaded to it from the web
> > > > > > >- Can't have changes merged into it until changes to files
> > that
> > > > > > > have a designated
> > > > > > >code owner  > articles/about-codeowners/>
> > > > > have
> > > > > > >been approved by that owner
> > > > > > >
> > > > > > >  I am sure many of us might not want to have all these but we
> can
> > > > > debate
> > > > > > on
> > > > > > > it. My main motive was to "*Can't have changes merged into it
> > until
> > > > > > > required status checks pass*"
> > > > > > >
> > > > > > >
> > > > > > > -Gautam
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Sep 27, 2017 at 11:09 PM, Chris Olivier <
> > > > cjolivie...@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > What does that mean? "Protected"? Protected from what?
> > > > > > > >
> > > > > > > > On Wed, Sep 27, 2017 at 11:08 PM Gautam <
> gautamn...@gmail.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Chris,
> > > > > > > > >
> > > > > > > > >I mean make "master branch protected" of  MXNet.
> > > > > > > > >
> > > > > > > > > -Gautam
> > > > > > > > >
> > > > > > > > > On Wed, Sep 27, 2017 at 11:04 PM, Chris Olivier <
> > > > > > cjolivie...@gmail.com
> > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > What does this mean? "Mx-net branch protected"?
> > > > > > > > > >
> > > > > > > > > > On Wed, Sep 27, 2017 at 9:59 PM Tsuyoshi OZAWA <
> > > > > > > > ozawa.tsuyo...@gmail.com
> > > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > +1,
> > > > > > > > > > >
> > > > > > > > > > > While I'm checking the recent build failures, and I
> think
> > > the
> >

Re: Apache MXNet build failures are mostly valid - verify before merge

[Naveen Swamy]

PR->Sanity test/Linux build/test->reviewer/committer approves the
change->Comment "Build Now" (Or trigger on at least one approval from a
committer other than author)->*Full build-*>*passes build*->Enable Merge

Let us take this particular topic to a separate thread or discuss offline
if further clarification is needed.

On Thu, Sep 28, 2017 at 11:24 AM, Chris Olivier 
wrote:

> I understand the proposal.  How to trigger a build in that case?
>
>
> On Thu, Sep 28, 2017 at 10:54 AM Madan Jampani 
> wrote:
>
> > Chris,
> > I don't think Naveen is suggesting that a merge happen without full
> > verification i.e. all tests across all platforms pass.
> > If a PR has some back and forth and results in multiple revisions (which
> is
> > arguably more common than a random unit test failing), we simply delay
> full
> > verification until the owner/reviewer have settled on a mutually
> acceptable
> > state.
> >
> > On Thu, Sep 28, 2017 at 10:25 AM, Chris Olivier 
> > wrote:
> >
> > > -1 for running only partial tests.  Most failing unit tests that get
> > > through fail only for certain platforms/configurations.  I personally
> > > prefer to be assured the build and test is good before merge.  Most PR
> > > merges aren't in a huge hurry.
> > >
> > > On Thu, Sep 28, 2017 at 9:54 AM, Naveen Swamy 
> > wrote:
> > >
> > > > +1 to make it protected. Here is what I am thinking for PR builds
> > > > on a PR run Sanity Tests + build/test one platform->committer reviews
> > the
> > > > code and issues "Build Now", a full build is run->Github checks that
> > the
> > > > full build checks succeed before it can be merged.
> > > >
> > > > I agree with Madan that PR should be approved by one another
> committer.
> > > >
> > > >
> > > >
> > > > On Thu, Sep 28, 2017 at 9:37 AM, Madan Jampani <
> > madan.jamp...@gmail.com>
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > At a minimum I'd like to see the following two happen:
> > > > > - Option to merge is disabled until all required checks pass.
> > > > > - Code is reviewed and given +1 by at least one other committer (no
> > > self
> > > > > review).
> > > > >
> > > > > On Wed, Sep 27, 2017 at 11:15 PM, Gautam 
> > wrote:
> > > > >
> > > > > > Hi Chris,
> > > > > >
> > > > > >   Here  branches/
> > >
> > > is
> > > > > > user
> > > > > > document on semantics of protected branch.
> > > > > > In short when a branch is protected following applies to that
> > branch.
> > > > > >
> > > > > >- Can't be force pushed
> > > > > >- Can't be deleted
> > > > > >- Can't have changes merged into it until required status
> checks
> > > > > > status-checks>
> > > > pass
> > > > > >- Can't have changes merged into it until required reviews are
> > > > > approved
> > > > > > > > > > > request-with-required-reviews>
> > > > > >- Can't be edited or have files uploaded to it from the web
> > > > > >- Can't have changes merged into it until changes to files
> that
> > > > > > have a designated
> > > > > >code owner  articles/about-codeowners/>
> > > > have
> > > > > >been approved by that owner
> > > > > >
> > > > > >  I am sure many of us might not want to have all these but we can
> > > > debate
> > > > > on
> > > > > > it. My main motive was to "*Can't have changes merged into it
> until
> > > > > > required status checks pass*"
> > > > > >
> > > > > >
> > > > > > -Gautam
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Sep 27, 2017 at 11:09 PM, Chris Olivier <
> > > cjolivie...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > What does that mean? "Protected"? Protected from what?
> > > > > > >
> > > > > > > On Wed, Sep 27, 2017 at 11:08 PM Gautam 
> > > > wrote:
> > > > > > >
> > > > > > > > Hi Chris,
> > > > > > > >
> > > > > > > >I mean make "master branch protected" of  MXNet.
> > > > > > > >
> > > > > > > > -Gautam
> > > > > > > >
> > > > > > > > On Wed, Sep 27, 2017 at 11:04 PM, Chris Olivier <
> > > > > cjolivie...@gmail.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > What does this mean? "Mx-net branch protected"?
> > > > > > > > >
> > > > > > > > > On Wed, Sep 27, 2017 at 9:59 PM Tsuyoshi OZAWA <
> > > > > > > ozawa.tsuyo...@gmail.com
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > +1,
> > > > > > > > > >
> > > > > > > > > > While I'm checking the recent build failures, and I think
> > the
> > > > > > > decision
> > > > > > > > > > of making the mx-net branch protected is necessary for
> > stable
> > > > > > > > > > building.
> > > > > > > > > > Thanks Kumar for resuming important discussion.
> > > > > > > > > >
> > > > > > > > > > Best regards
> > > > > > > > > > - Tsuyoshi
> > > > > > > > > >
> > > > > > > > > > On Thu, Sep 28, 2017 at 12:56 PM, Kumar, Gautam <
> > > > > ga...@

Re: Apache MXNet build failures are mostly valid - verify before merge

[Chris Olivier]

I understand the proposal.  How to trigger a build in that case?


On Thu, Sep 28, 2017 at 10:54 AM Madan Jampani 
wrote:

> Chris,
> I don't think Naveen is suggesting that a merge happen without full
> verification i.e. all tests across all platforms pass.
> If a PR has some back and forth and results in multiple revisions (which is
> arguably more common than a random unit test failing), we simply delay full
> verification until the owner/reviewer have settled on a mutually acceptable
> state.
>
> On Thu, Sep 28, 2017 at 10:25 AM, Chris Olivier 
> wrote:
>
> > -1 for running only partial tests.  Most failing unit tests that get
> > through fail only for certain platforms/configurations.  I personally
> > prefer to be assured the build and test is good before merge.  Most PR
> > merges aren't in a huge hurry.
> >
> > On Thu, Sep 28, 2017 at 9:54 AM, Naveen Swamy 
> wrote:
> >
> > > +1 to make it protected. Here is what I am thinking for PR builds
> > > on a PR run Sanity Tests + build/test one platform->committer reviews
> the
> > > code and issues "Build Now", a full build is run->Github checks that
> the
> > > full build checks succeed before it can be merged.
> > >
> > > I agree with Madan that PR should be approved by one another committer.
> > >
> > >
> > >
> > > On Thu, Sep 28, 2017 at 9:37 AM, Madan Jampani <
> madan.jamp...@gmail.com>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > At a minimum I'd like to see the following two happen:
> > > > - Option to merge is disabled until all required checks pass.
> > > > - Code is reviewed and given +1 by at least one other committer (no
> > self
> > > > review).
> > > >
> > > > On Wed, Sep 27, 2017 at 11:15 PM, Gautam 
> wrote:
> > > >
> > > > > Hi Chris,
> > > > >
> > > > >   Here  >
> > is
> > > > > user
> > > > > document on semantics of protected branch.
> > > > > In short when a branch is protected following applies to that
> branch.
> > > > >
> > > > >- Can't be force pushed
> > > > >- Can't be deleted
> > > > >- Can't have changes merged into it until required status checks
> > > > >
> > > pass
> > > > >- Can't have changes merged into it until required reviews are
> > > > approved
> > > > > > > > > request-with-required-reviews>
> > > > >- Can't be edited or have files uploaded to it from the web
> > > > >- Can't have changes merged into it until changes to files that
> > > > > have a designated
> > > > >code owner 
> > > have
> > > > >been approved by that owner
> > > > >
> > > > >  I am sure many of us might not want to have all these but we can
> > > debate
> > > > on
> > > > > it. My main motive was to "*Can't have changes merged into it until
> > > > > required status checks pass*"
> > > > >
> > > > >
> > > > > -Gautam
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Sep 27, 2017 at 11:09 PM, Chris Olivier <
> > cjolivie...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > What does that mean? "Protected"? Protected from what?
> > > > > >
> > > > > > On Wed, Sep 27, 2017 at 11:08 PM Gautam 
> > > wrote:
> > > > > >
> > > > > > > Hi Chris,
> > > > > > >
> > > > > > >I mean make "master branch protected" of  MXNet.
> > > > > > >
> > > > > > > -Gautam
> > > > > > >
> > > > > > > On Wed, Sep 27, 2017 at 11:04 PM, Chris Olivier <
> > > > cjolivie...@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > What does this mean? "Mx-net branch protected"?
> > > > > > > >
> > > > > > > > On Wed, Sep 27, 2017 at 9:59 PM Tsuyoshi OZAWA <
> > > > > > ozawa.tsuyo...@gmail.com
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > +1,
> > > > > > > > >
> > > > > > > > > While I'm checking the recent build failures, and I think
> the
> > > > > > decision
> > > > > > > > > of making the mx-net branch protected is necessary for
> stable
> > > > > > > > > building.
> > > > > > > > > Thanks Kumar for resuming important discussion.
> > > > > > > > >
> > > > > > > > > Best regards
> > > > > > > > > - Tsuyoshi
> > > > > > > > >
> > > > > > > > > On Thu, Sep 28, 2017 at 12:56 PM, Kumar, Gautam <
> > > > ga...@amazon.com>
> > > > > > > > wrote:
> > > > > > > > > > Reviving the discussion.
> > > > > > > > > >
> > > > > > > > > > At this point of time we have couple of stable builds
> > > > > > > > > >
> > > > > > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > > > > > incubator-mxnet/job/master/448/
> > > > > > > > > >
> > > > > > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > > > > > incubator-mxnet/job/master/449/
> > > > > > > > > >
> > > > > > > > > > Should we have a quick discussion or polling on making
> the
> > > > mx-net
> > > > > > > > branch
> > > > > > > > > protected? If you still think we shouldn’t ma

Re: Apache MXNet build failures are mostly valid - verify before merge

[Madan Jampani]

Chris,
I don't think Naveen is suggesting that a merge happen without full
verification i.e. all tests across all platforms pass.
If a PR has some back and forth and results in multiple revisions (which is
arguably more common than a random unit test failing), we simply delay full
verification until the owner/reviewer have settled on a mutually acceptable
state.

On Thu, Sep 28, 2017 at 10:25 AM, Chris Olivier 
wrote:

> -1 for running only partial tests.  Most failing unit tests that get
> through fail only for certain platforms/configurations.  I personally
> prefer to be assured the build and test is good before merge.  Most PR
> merges aren't in a huge hurry.
>
> On Thu, Sep 28, 2017 at 9:54 AM, Naveen Swamy  wrote:
>
> > +1 to make it protected. Here is what I am thinking for PR builds
> > on a PR run Sanity Tests + build/test one platform->committer reviews the
> > code and issues "Build Now", a full build is run->Github checks that the
> > full build checks succeed before it can be merged.
> >
> > I agree with Madan that PR should be approved by one another committer.
> >
> >
> >
> > On Thu, Sep 28, 2017 at 9:37 AM, Madan Jampani 
> > wrote:
> >
> > > +1
> > >
> > > At a minimum I'd like to see the following two happen:
> > > - Option to merge is disabled until all required checks pass.
> > > - Code is reviewed and given +1 by at least one other committer (no
> self
> > > review).
> > >
> > > On Wed, Sep 27, 2017 at 11:15 PM, Gautam  wrote:
> > >
> > > > Hi Chris,
> > > >
> > > >   Here 
> is
> > > > user
> > > > document on semantics of protected branch.
> > > > In short when a branch is protected following applies to that branch.
> > > >
> > > >- Can't be force pushed
> > > >- Can't be deleted
> > > >- Can't have changes merged into it until required status checks
> > > >
> > pass
> > > >- Can't have changes merged into it until required reviews are
> > > approved
> > > > > > > request-with-required-reviews>
> > > >- Can't be edited or have files uploaded to it from the web
> > > >- Can't have changes merged into it until changes to files that
> > > > have a designated
> > > >code owner 
> > have
> > > >been approved by that owner
> > > >
> > > >  I am sure many of us might not want to have all these but we can
> > debate
> > > on
> > > > it. My main motive was to "*Can't have changes merged into it until
> > > > required status checks pass*"
> > > >
> > > >
> > > > -Gautam
> > > >
> > > >
> > > >
> > > > On Wed, Sep 27, 2017 at 11:09 PM, Chris Olivier <
> cjolivie...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > What does that mean? "Protected"? Protected from what?
> > > > >
> > > > > On Wed, Sep 27, 2017 at 11:08 PM Gautam 
> > wrote:
> > > > >
> > > > > > Hi Chris,
> > > > > >
> > > > > >I mean make "master branch protected" of  MXNet.
> > > > > >
> > > > > > -Gautam
> > > > > >
> > > > > > On Wed, Sep 27, 2017 at 11:04 PM, Chris Olivier <
> > > cjolivie...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > What does this mean? "Mx-net branch protected"?
> > > > > > >
> > > > > > > On Wed, Sep 27, 2017 at 9:59 PM Tsuyoshi OZAWA <
> > > > > ozawa.tsuyo...@gmail.com
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > +1,
> > > > > > > >
> > > > > > > > While I'm checking the recent build failures, and I think the
> > > > > decision
> > > > > > > > of making the mx-net branch protected is necessary for stable
> > > > > > > > building.
> > > > > > > > Thanks Kumar for resuming important discussion.
> > > > > > > >
> > > > > > > > Best regards
> > > > > > > > - Tsuyoshi
> > > > > > > >
> > > > > > > > On Thu, Sep 28, 2017 at 12:56 PM, Kumar, Gautam <
> > > ga...@amazon.com>
> > > > > > > wrote:
> > > > > > > > > Reviving the discussion.
> > > > > > > > >
> > > > > > > > > At this point of time we have couple of stable builds
> > > > > > > > >
> > > > > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > > > > incubator-mxnet/job/master/448/
> > > > > > > > >
> > > > > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > > > > incubator-mxnet/job/master/449/
> > > > > > > > >
> > > > > > > > > Should we have a quick discussion or polling on making the
> > > mx-net
> > > > > > > branch
> > > > > > > > protected? If you still think we shouldn’t make it protected
> > > please
> > > > > > > provide
> > > > > > > > a reason to support your claim.
> > > > > > > > >
> > > > > > > > > Few of us have concern over Jenkin’s stability. If I look
> two
> > > > weeks
> > > > > > > > back, after upgrading Linux slave to g2.8x and new windows
> AMI,
> > > we
> > > > > have
> > > > > > > not
> > > > > > > > seen any case where instance died due to high memory usage or
> > any
> > > >

Re: PR builds are currently failing due to a known issue

[Daniel Pono Takamori]

Unfortunately we won't be able to enable all the Groovy methods for
security reasons.  Fortunately the Beam team has found some work
arounds for this so I'm cc'ing them to connect you to figure out how
to get around this issue.

Jason, if you could point the MXNet folks to your builds repo so they
could take a look and ask questions, that would be great!

On Thu, Sep 28, 2017 at 10:59 AM, Naveen Swamy  wrote:
> Please revert this change until Apache Infra approve all the required
> scripts? I don't think we should let the PR builds continue to fail this
> long.
>
> On Wed, Sep 27, 2017 at 3:57 PM, Meghna Baijal 
> wrote:
>
>> Hi All,
>> This is just to let everyone know that PR #8034 is breaking the Apache
>> MXNet PR builds for the moment. The master branch is not affected by this.
>>
>> This PR makes changes to the Jenkinsfile and some script approvals are
>> required from the Apache infra team. I have opened a JIRA ticket for the
>> same -https://issues.apache.org/jira/browse/INFRA-15176 <
>> https://issues.apache.org/jira/browse/INFRA-15176> and we are in the
>> process of resolving it.
>>
>> I will update this thread once the issue is fixed.
>>
>> Thanks,
>> Meghna Baijal
>>
>>

Re: Apache MXNet build failures are mostly valid - verify before merge

[Chris Olivier]

-1 for running only partial tests.  Most failing unit tests that get
through fail only for certain platforms/configurations.  I personally
prefer to be assured the build and test is good before merge.  Most PR
merges aren't in a huge hurry.

On Thu, Sep 28, 2017 at 9:54 AM, Naveen Swamy  wrote:

> +1 to make it protected. Here is what I am thinking for PR builds
> on a PR run Sanity Tests + build/test one platform->committer reviews the
> code and issues "Build Now", a full build is run->Github checks that the
> full build checks succeed before it can be merged.
>
> I agree with Madan that PR should be approved by one another committer.
>
>
>
> On Thu, Sep 28, 2017 at 9:37 AM, Madan Jampani 
> wrote:
>
> > +1
> >
> > At a minimum I'd like to see the following two happen:
> > - Option to merge is disabled until all required checks pass.
> > - Code is reviewed and given +1 by at least one other committer (no self
> > review).
> >
> > On Wed, Sep 27, 2017 at 11:15 PM, Gautam  wrote:
> >
> > > Hi Chris,
> > >
> > >   Here  is
> > > user
> > > document on semantics of protected branch.
> > > In short when a branch is protected following applies to that branch.
> > >
> > >- Can't be force pushed
> > >- Can't be deleted
> > >- Can't have changes merged into it until required status checks
> > >
> pass
> > >- Can't have changes merged into it until required reviews are
> > approved
> > > > > request-with-required-reviews>
> > >- Can't be edited or have files uploaded to it from the web
> > >- Can't have changes merged into it until changes to files that
> > > have a designated
> > >code owner 
> have
> > >been approved by that owner
> > >
> > >  I am sure many of us might not want to have all these but we can
> debate
> > on
> > > it. My main motive was to "*Can't have changes merged into it until
> > > required status checks pass*"
> > >
> > >
> > > -Gautam
> > >
> > >
> > >
> > > On Wed, Sep 27, 2017 at 11:09 PM, Chris Olivier  >
> > > wrote:
> > >
> > > > What does that mean? "Protected"? Protected from what?
> > > >
> > > > On Wed, Sep 27, 2017 at 11:08 PM Gautam 
> wrote:
> > > >
> > > > > Hi Chris,
> > > > >
> > > > >I mean make "master branch protected" of  MXNet.
> > > > >
> > > > > -Gautam
> > > > >
> > > > > On Wed, Sep 27, 2017 at 11:04 PM, Chris Olivier <
> > cjolivie...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > What does this mean? "Mx-net branch protected"?
> > > > > >
> > > > > > On Wed, Sep 27, 2017 at 9:59 PM Tsuyoshi OZAWA <
> > > > ozawa.tsuyo...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > +1,
> > > > > > >
> > > > > > > While I'm checking the recent build failures, and I think the
> > > > decision
> > > > > > > of making the mx-net branch protected is necessary for stable
> > > > > > > building.
> > > > > > > Thanks Kumar for resuming important discussion.
> > > > > > >
> > > > > > > Best regards
> > > > > > > - Tsuyoshi
> > > > > > >
> > > > > > > On Thu, Sep 28, 2017 at 12:56 PM, Kumar, Gautam <
> > ga...@amazon.com>
> > > > > > wrote:
> > > > > > > > Reviving the discussion.
> > > > > > > >
> > > > > > > > At this point of time we have couple of stable builds
> > > > > > > >
> > > > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > > > incubator-mxnet/job/master/448/
> > > > > > > >
> > > > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > > > incubator-mxnet/job/master/449/
> > > > > > > >
> > > > > > > > Should we have a quick discussion or polling on making the
> > mx-net
> > > > > > branch
> > > > > > > protected? If you still think we shouldn’t make it protected
> > please
> > > > > > provide
> > > > > > > a reason to support your claim.
> > > > > > > >
> > > > > > > > Few of us have concern over Jenkin’s stability. If I look two
> > > weeks
> > > > > > > back, after upgrading Linux slave to g2.8x and new windows AMI,
> > we
> > > > have
> > > > > > not
> > > > > > > seen any case where instance died due to high memory usage or
> any
> > > > > process
> > > > > > > got killed due to high cpu usage or any other issue with
> windows
> > > > > slaves.
> > > > > > > >
> > > > > > > > Going forward we are also planning that if we add any new
> slave
> > > we
> > > > > will
> > > > > > > not enable the main load immediately, but rather will do ‘test
> > > build’
> > > > > to
> > > > > > > make sure that new slaves are not causing any infrastructure
> > issue
> > > > and
> > > > > > > capable to perform as good as existing slaves.
> > > > > > > >
> > > > > > > > -Gautam
> > > > > > > >
> > > > > > > > On 8/31/17, 5:27 PM, "Lupesko, Hagay" 
> > wrote:
> > > > > > > >
> > > > > > > > @madan looking into some failures – you’re right… there’s
> > >

Re: Apache MXNet build failures are mostly valid - verify before merge

[Tsuyoshi Ozawa]

> At a minimum I'd like to see the following two happen:
> - Option to merge is disabled until all required checks pass.
> - Code is reviewed and given +1 by at least one other committer (no self 
> review).

I like this policy. In fact, Apache Hadoop community works with the
policy too. Thanks for your good summary, Madan.

>  And as I explained, we wouldn't need to run extensive tests on every PR, 
> just nightly on staging.

Or, we have another option since we have limited test resources: a
privileged person's commenting on something like "ready to test" on
github PR to launch Jenkins CI like Apache Spark. I think we need more
additional infra setup for doing this, though.
https://github.com/apache/spark/pull/19181#issuecomment-328809979

On Fri, Sep 29, 2017 at 1:37 AM, Madan Jampani  wrote:
> +1
>
> At a minimum I'd like to see the following two happen:
> - Option to merge is disabled until all required checks pass.
> - Code is reviewed and given +1 by at least one other committer (no self
> review).
>
> On Wed, Sep 27, 2017 at 11:15 PM, Gautam  wrote:
>
>> Hi Chris,
>>
>>   Here  is
>> user
>> document on semantics of protected branch.
>> In short when a branch is protected following applies to that branch.
>>
>>- Can't be force pushed
>>- Can't be deleted
>>- Can't have changes merged into it until required status checks
>> pass
>>- Can't have changes merged into it until required reviews are approved
>>> request-with-required-reviews>
>>- Can't be edited or have files uploaded to it from the web
>>- Can't have changes merged into it until changes to files that
>> have a designated
>>code owner  have
>>been approved by that owner
>>
>>  I am sure many of us might not want to have all these but we can debate on
>> it. My main motive was to "*Can't have changes merged into it until
>> required status checks pass*"
>>
>>
>> -Gautam
>>
>>
>>
>> On Wed, Sep 27, 2017 at 11:09 PM, Chris Olivier 
>> wrote:
>>
>> > What does that mean? "Protected"? Protected from what?
>> >
>> > On Wed, Sep 27, 2017 at 11:08 PM Gautam  wrote:
>> >
>> > > Hi Chris,
>> > >
>> > >I mean make "master branch protected" of  MXNet.
>> > >
>> > > -Gautam
>> > >
>> > > On Wed, Sep 27, 2017 at 11:04 PM, Chris Olivier > >
>> > > wrote:
>> > >
>> > > > What does this mean? "Mx-net branch protected"?
>> > > >
>> > > > On Wed, Sep 27, 2017 at 9:59 PM Tsuyoshi OZAWA <
>> > ozawa.tsuyo...@gmail.com
>> > > >
>> > > > wrote:
>> > > >
>> > > > > +1,
>> > > > >
>> > > > > While I'm checking the recent build failures, and I think the
>> > decision
>> > > > > of making the mx-net branch protected is necessary for stable
>> > > > > building.
>> > > > > Thanks Kumar for resuming important discussion.
>> > > > >
>> > > > > Best regards
>> > > > > - Tsuyoshi
>> > > > >
>> > > > > On Thu, Sep 28, 2017 at 12:56 PM, Kumar, Gautam 
>> > > > wrote:
>> > > > > > Reviving the discussion.
>> > > > > >
>> > > > > > At this point of time we have couple of stable builds
>> > > > > >
>> > > > > https://builds.apache.org/view/Incubator%20Projects/job/
>> > > > incubator-mxnet/job/master/448/
>> > > > > >
>> > > > > https://builds.apache.org/view/Incubator%20Projects/job/
>> > > > incubator-mxnet/job/master/449/
>> > > > > >
>> > > > > > Should we have a quick discussion or polling on making the mx-net
>> > > > branch
>> > > > > protected? If you still think we shouldn’t make it protected please
>> > > > provide
>> > > > > a reason to support your claim.
>> > > > > >
>> > > > > > Few of us have concern over Jenkin’s stability. If I look two
>> weeks
>> > > > > back, after upgrading Linux slave to g2.8x and new windows AMI, we
>> > have
>> > > > not
>> > > > > seen any case where instance died due to high memory usage or any
>> > > process
>> > > > > got killed due to high cpu usage or any other issue with windows
>> > > slaves.
>> > > > > >
>> > > > > > Going forward we are also planning that if we add any new slave
>> we
>> > > will
>> > > > > not enable the main load immediately, but rather will do ‘test
>> build’
>> > > to
>> > > > > make sure that new slaves are not causing any infrastructure issue
>> > and
>> > > > > capable to perform as good as existing slaves.
>> > > > > >
>> > > > > > -Gautam
>> > > > > >
>> > > > > > On 8/31/17, 5:27 PM, "Lupesko, Hagay"  wrote:
>> > > > > >
>> > > > > > @madan looking into some failures – you’re right… there’s
>> > > multiple
>> > > > > issues going on, some of them intermittent, and we want to be able
>> to
>> > > > merge
>> > > > > fixes in.
>> > > > > > Agreed that we can wait with setting up protected mode until
>> > > build
>> > > > > stabilizes.
>> > > > > >
>> > > > > > On 8/31/17, 11:41, "Madan Jampani" 
>> > > > wrote:
>> > > > > >

Re: Apache MXNet build failures are mostly valid - verify before merge

[Chris Olivier]

+1

On Thu, Sep 28, 2017 at 9:37 AM, Madan Jampani 
wrote:

> +1
>
> At a minimum I'd like to see the following two happen:
> - Option to merge is disabled until all required checks pass.
> - Code is reviewed and given +1 by at least one other committer (no self
> review).
>
> On Wed, Sep 27, 2017 at 11:15 PM, Gautam  wrote:
>
> > Hi Chris,
> >
> >   Here  is
> > user
> > document on semantics of protected branch.
> > In short when a branch is protected following applies to that branch.
> >
> >- Can't be force pushed
> >- Can't be deleted
> >- Can't have changes merged into it until required status checks
> > pass
> >- Can't have changes merged into it until required reviews are
> approved
> > > request-with-required-reviews>
> >- Can't be edited or have files uploaded to it from the web
> >- Can't have changes merged into it until changes to files that
> > have a designated
> >code owner  have
> >been approved by that owner
> >
> >  I am sure many of us might not want to have all these but we can debate
> on
> > it. My main motive was to "*Can't have changes merged into it until
> > required status checks pass*"
> >
> >
> > -Gautam
> >
> >
> >
> > On Wed, Sep 27, 2017 at 11:09 PM, Chris Olivier 
> > wrote:
> >
> > > What does that mean? "Protected"? Protected from what?
> > >
> > > On Wed, Sep 27, 2017 at 11:08 PM Gautam  wrote:
> > >
> > > > Hi Chris,
> > > >
> > > >I mean make "master branch protected" of  MXNet.
> > > >
> > > > -Gautam
> > > >
> > > > On Wed, Sep 27, 2017 at 11:04 PM, Chris Olivier <
> cjolivie...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > What does this mean? "Mx-net branch protected"?
> > > > >
> > > > > On Wed, Sep 27, 2017 at 9:59 PM Tsuyoshi OZAWA <
> > > ozawa.tsuyo...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > +1,
> > > > > >
> > > > > > While I'm checking the recent build failures, and I think the
> > > decision
> > > > > > of making the mx-net branch protected is necessary for stable
> > > > > > building.
> > > > > > Thanks Kumar for resuming important discussion.
> > > > > >
> > > > > > Best regards
> > > > > > - Tsuyoshi
> > > > > >
> > > > > > On Thu, Sep 28, 2017 at 12:56 PM, Kumar, Gautam <
> ga...@amazon.com>
> > > > > wrote:
> > > > > > > Reviving the discussion.
> > > > > > >
> > > > > > > At this point of time we have couple of stable builds
> > > > > > >
> > > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > > incubator-mxnet/job/master/448/
> > > > > > >
> > > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > > incubator-mxnet/job/master/449/
> > > > > > >
> > > > > > > Should we have a quick discussion or polling on making the
> mx-net
> > > > > branch
> > > > > > protected? If you still think we shouldn’t make it protected
> please
> > > > > provide
> > > > > > a reason to support your claim.
> > > > > > >
> > > > > > > Few of us have concern over Jenkin’s stability. If I look two
> > weeks
> > > > > > back, after upgrading Linux slave to g2.8x and new windows AMI,
> we
> > > have
> > > > > not
> > > > > > seen any case where instance died due to high memory usage or any
> > > > process
> > > > > > got killed due to high cpu usage or any other issue with windows
> > > > slaves.
> > > > > > >
> > > > > > > Going forward we are also planning that if we add any new slave
> > we
> > > > will
> > > > > > not enable the main load immediately, but rather will do ‘test
> > build’
> > > > to
> > > > > > make sure that new slaves are not causing any infrastructure
> issue
> > > and
> > > > > > capable to perform as good as existing slaves.
> > > > > > >
> > > > > > > -Gautam
> > > > > > >
> > > > > > > On 8/31/17, 5:27 PM, "Lupesko, Hagay" 
> wrote:
> > > > > > >
> > > > > > > @madan looking into some failures – you’re right… there’s
> > > > multiple
> > > > > > issues going on, some of them intermittent, and we want to be
> able
> > to
> > > > > merge
> > > > > > fixes in.
> > > > > > > Agreed that we can wait with setting up protected mode
> until
> > > > build
> > > > > > stabilizes.
> > > > > > >
> > > > > > > On 8/31/17, 11:41, "Madan Jampani" <
> madan.jamp...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > @hagay: we agree on the end state. I'm not too
> particular
> > > > about
> > > > > > how we get
> > > > > > > there. If you think enabling it now and fixes
> regression
> > > > later
> > > > > > is doable,
> > > > > > > I'm fine with. I see a bit of a chicken and egg
> problem.
> > We
> > > > > need
> > > > > > to get
> > > > > > > some fixes in even when the status checks are failing.
> > > > > > >
> > > > > > > On Thu, Aug 31, 2017 at 11:25 AM, Lupesko, Hagay <
> > > > > >

Re: Apache MXNet build failures are mostly valid - verify before merge

[Naveen Swamy]

+1 to make it protected. Here is what I am thinking for PR builds
on a PR run Sanity Tests + build/test one platform->committer reviews the
code and issues "Build Now", a full build is run->Github checks that the
full build checks succeed before it can be merged.

I agree with Madan that PR should be approved by one another committer.



On Thu, Sep 28, 2017 at 9:37 AM, Madan Jampani 
wrote:

> +1
>
> At a minimum I'd like to see the following two happen:
> - Option to merge is disabled until all required checks pass.
> - Code is reviewed and given +1 by at least one other committer (no self
> review).
>
> On Wed, Sep 27, 2017 at 11:15 PM, Gautam  wrote:
>
> > Hi Chris,
> >
> >   Here  is
> > user
> > document on semantics of protected branch.
> > In short when a branch is protected following applies to that branch.
> >
> >- Can't be force pushed
> >- Can't be deleted
> >- Can't have changes merged into it until required status checks
> > pass
> >- Can't have changes merged into it until required reviews are
> approved
> > > request-with-required-reviews>
> >- Can't be edited or have files uploaded to it from the web
> >- Can't have changes merged into it until changes to files that
> > have a designated
> >code owner  have
> >been approved by that owner
> >
> >  I am sure many of us might not want to have all these but we can debate
> on
> > it. My main motive was to "*Can't have changes merged into it until
> > required status checks pass*"
> >
> >
> > -Gautam
> >
> >
> >
> > On Wed, Sep 27, 2017 at 11:09 PM, Chris Olivier 
> > wrote:
> >
> > > What does that mean? "Protected"? Protected from what?
> > >
> > > On Wed, Sep 27, 2017 at 11:08 PM Gautam  wrote:
> > >
> > > > Hi Chris,
> > > >
> > > >I mean make "master branch protected" of  MXNet.
> > > >
> > > > -Gautam
> > > >
> > > > On Wed, Sep 27, 2017 at 11:04 PM, Chris Olivier <
> cjolivie...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > What does this mean? "Mx-net branch protected"?
> > > > >
> > > > > On Wed, Sep 27, 2017 at 9:59 PM Tsuyoshi OZAWA <
> > > ozawa.tsuyo...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > +1,
> > > > > >
> > > > > > While I'm checking the recent build failures, and I think the
> > > decision
> > > > > > of making the mx-net branch protected is necessary for stable
> > > > > > building.
> > > > > > Thanks Kumar for resuming important discussion.
> > > > > >
> > > > > > Best regards
> > > > > > - Tsuyoshi
> > > > > >
> > > > > > On Thu, Sep 28, 2017 at 12:56 PM, Kumar, Gautam <
> ga...@amazon.com>
> > > > > wrote:
> > > > > > > Reviving the discussion.
> > > > > > >
> > > > > > > At this point of time we have couple of stable builds
> > > > > > >
> > > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > > incubator-mxnet/job/master/448/
> > > > > > >
> > > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > > incubator-mxnet/job/master/449/
> > > > > > >
> > > > > > > Should we have a quick discussion or polling on making the
> mx-net
> > > > > branch
> > > > > > protected? If you still think we shouldn’t make it protected
> please
> > > > > provide
> > > > > > a reason to support your claim.
> > > > > > >
> > > > > > > Few of us have concern over Jenkin’s stability. If I look two
> > weeks
> > > > > > back, after upgrading Linux slave to g2.8x and new windows AMI,
> we
> > > have
> > > > > not
> > > > > > seen any case where instance died due to high memory usage or any
> > > > process
> > > > > > got killed due to high cpu usage or any other issue with windows
> > > > slaves.
> > > > > > >
> > > > > > > Going forward we are also planning that if we add any new slave
> > we
> > > > will
> > > > > > not enable the main load immediately, but rather will do ‘test
> > build’
> > > > to
> > > > > > make sure that new slaves are not causing any infrastructure
> issue
> > > and
> > > > > > capable to perform as good as existing slaves.
> > > > > > >
> > > > > > > -Gautam
> > > > > > >
> > > > > > > On 8/31/17, 5:27 PM, "Lupesko, Hagay" 
> wrote:
> > > > > > >
> > > > > > > @madan looking into some failures – you’re right… there’s
> > > > multiple
> > > > > > issues going on, some of them intermittent, and we want to be
> able
> > to
> > > > > merge
> > > > > > fixes in.
> > > > > > > Agreed that we can wait with setting up protected mode
> until
> > > > build
> > > > > > stabilizes.
> > > > > > >
> > > > > > > On 8/31/17, 11:41, "Madan Jampani" <
> madan.jamp...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > @hagay: we agree on the end state. I'm not too
> particular
> > > > about
> > > > > > how we get
> > > > > > > there. If you think enabling it now and fixes
> regressio

Re: PR builds are currently failing due to a known issue

[Naveen Swamy]

Please revert this change until Apache Infra approve all the required
scripts? I don't think we should let the PR builds continue to fail this
long.

On Wed, Sep 27, 2017 at 3:57 PM, Meghna Baijal 
wrote:

> Hi All,
> This is just to let everyone know that PR #8034 is breaking the Apache
> MXNet PR builds for the moment. The master branch is not affected by this.
>
> This PR makes changes to the Jenkinsfile and some script approvals are
> required from the Apache infra team. I have opened a JIRA ticket for the
> same -https://issues.apache.org/jira/browse/INFRA-15176 <
> https://issues.apache.org/jira/browse/INFRA-15176> and we are in the
> process of resolving it.
>
> I will update this thread once the issue is fixed.
>
> Thanks,
> Meghna Baijal
>
>

Re: Apache MXNet build failures are mostly valid - verify before merge

[Madan Jampani]

+1

At a minimum I'd like to see the following two happen:
- Option to merge is disabled until all required checks pass.
- Code is reviewed and given +1 by at least one other committer (no self
review).

On Wed, Sep 27, 2017 at 11:15 PM, Gautam  wrote:

> Hi Chris,
>
>   Here  is
> user
> document on semantics of protected branch.
> In short when a branch is protected following applies to that branch.
>
>- Can't be force pushed
>- Can't be deleted
>- Can't have changes merged into it until required status checks
> pass
>- Can't have changes merged into it until required reviews are approved
> request-with-required-reviews>
>- Can't be edited or have files uploaded to it from the web
>- Can't have changes merged into it until changes to files that
> have a designated
>code owner  have
>been approved by that owner
>
>  I am sure many of us might not want to have all these but we can debate on
> it. My main motive was to "*Can't have changes merged into it until
> required status checks pass*"
>
>
> -Gautam
>
>
>
> On Wed, Sep 27, 2017 at 11:09 PM, Chris Olivier 
> wrote:
>
> > What does that mean? "Protected"? Protected from what?
> >
> > On Wed, Sep 27, 2017 at 11:08 PM Gautam  wrote:
> >
> > > Hi Chris,
> > >
> > >I mean make "master branch protected" of  MXNet.
> > >
> > > -Gautam
> > >
> > > On Wed, Sep 27, 2017 at 11:04 PM, Chris Olivier  >
> > > wrote:
> > >
> > > > What does this mean? "Mx-net branch protected"?
> > > >
> > > > On Wed, Sep 27, 2017 at 9:59 PM Tsuyoshi OZAWA <
> > ozawa.tsuyo...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > +1,
> > > > >
> > > > > While I'm checking the recent build failures, and I think the
> > decision
> > > > > of making the mx-net branch protected is necessary for stable
> > > > > building.
> > > > > Thanks Kumar for resuming important discussion.
> > > > >
> > > > > Best regards
> > > > > - Tsuyoshi
> > > > >
> > > > > On Thu, Sep 28, 2017 at 12:56 PM, Kumar, Gautam 
> > > > wrote:
> > > > > > Reviving the discussion.
> > > > > >
> > > > > > At this point of time we have couple of stable builds
> > > > > >
> > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > incubator-mxnet/job/master/448/
> > > > > >
> > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > incubator-mxnet/job/master/449/
> > > > > >
> > > > > > Should we have a quick discussion or polling on making the mx-net
> > > > branch
> > > > > protected? If you still think we shouldn’t make it protected please
> > > > provide
> > > > > a reason to support your claim.
> > > > > >
> > > > > > Few of us have concern over Jenkin’s stability. If I look two
> weeks
> > > > > back, after upgrading Linux slave to g2.8x and new windows AMI, we
> > have
> > > > not
> > > > > seen any case where instance died due to high memory usage or any
> > > process
> > > > > got killed due to high cpu usage or any other issue with windows
> > > slaves.
> > > > > >
> > > > > > Going forward we are also planning that if we add any new slave
> we
> > > will
> > > > > not enable the main load immediately, but rather will do ‘test
> build’
> > > to
> > > > > make sure that new slaves are not causing any infrastructure issue
> > and
> > > > > capable to perform as good as existing slaves.
> > > > > >
> > > > > > -Gautam
> > > > > >
> > > > > > On 8/31/17, 5:27 PM, "Lupesko, Hagay"  wrote:
> > > > > >
> > > > > > @madan looking into some failures – you’re right… there’s
> > > multiple
> > > > > issues going on, some of them intermittent, and we want to be able
> to
> > > > merge
> > > > > fixes in.
> > > > > > Agreed that we can wait with setting up protected mode until
> > > build
> > > > > stabilizes.
> > > > > >
> > > > > > On 8/31/17, 11:41, "Madan Jampani" 
> > > > wrote:
> > > > > >
> > > > > > @hagay: we agree on the end state. I'm not too particular
> > > about
> > > > > how we get
> > > > > > there. If you think enabling it now and fixes regression
> > > later
> > > > > is doable,
> > > > > > I'm fine with. I see a bit of a chicken and egg problem.
> We
> > > > need
> > > > > to get
> > > > > > some fixes in even when the status checks are failing.
> > > > > >
> > > > > > On Thu, Aug 31, 2017 at 11:25 AM, Lupesko, Hagay <
> > > > > lupe...@gmail.com> wrote:
> > > > > >
> > > > > > > @madan – re: getting to a stable CI first:
> > > > > > > I’m concerned that by not enabling protected branch
> mode
> > > > ASAP,
> > > > > we’re just
> > > > > > > taking in more regressions, which makes a stable build
> a
> > > > > moving target for
> > > > > > > us…
> > > > > > >
> > > > > > > On 8/31/17, 10:49, "Zha, Sheng" 
> > > wro

Re: Apache MXNet build failures are mostly valid - verify before merge

[Pedro Larroy]

Given the cost of running all the test for all the build flavors and
architectures I would propose the following:



   - Have a staging branch were PRs are merged by committers which runs all
   the integration tests with the appropriate frequency (say nightly).
   - Have automated fast forwards from the staging branch done
   automatically by Jenkins when the latest head passes all the tests for all
   platforms.



With this we would always have a stable master branch which is well tested,
while being able to adjust the tradeoff between correctness and quick
feedback for PRs.

Another improvement would be to split the feedback in stages, one would be
multi-platform / multi-flavor build which should be around 20 minutes, and
then two or more stages of quick tests and extensive tests. And as I
explained, we wouldn't need to run extensive tests on every PR, just
nightly on staging.

What do you think?

Pedro.

On Thu, Sep 28, 2017 at 2:02 PM, Joern Kottmann  wrote:

> At Apache OpenNLP we just established among committers that you check
> that the status indicator is green before you merge,
> and if it wasn't the case then we would ask the committer to take
> responsibility and repair things. Works very well our build is never
> broken.
>
> We also strongly prefer if each PR gets reviewed by another committer.
>
> Overall this works quite well. We don't use any of the protections
> against merging, it is important that you can trust each of the
> committers not to break things, if there are problems it is better to
> resolve them with talking to each other, rather than enforcing green
> status checks.
>
> Jörn
>
> On Thu, Sep 28, 2017 at 8:21 AM, Chris Olivier 
> wrote:
> > +1 on that
> >
> > On Wed, Sep 27, 2017 at 11:15 PM Gautam  wrote:
> >
> >> Hi Chris,
> >>
> >>   Here  is
> >> user
> >> document on semantics of protected branch.
> >> In short when a branch is protected following applies to that branch.
> >>
> >>- Can't be force pushed
> >>- Can't be deleted
> >>- Can't have changes merged into it until required status checks
> >> pass
> >>- Can't have changes merged into it until required reviews are
> approved
> >><
> >> https://help.github.com/articles/approving-a-pull-
> request-with-required-reviews
> >> >
> >>- Can't be edited or have files uploaded to it from the web
> >>- Can't have changes merged into it until changes to files that
> >> have a designated
> >>code owner  have
> >>been approved by that owner
> >>
> >>  I am sure many of us might not want to have all these but we can
> debate on
> >> it. My main motive was to "*Can't have changes merged into it until
> >> required status checks pass*"
> >>
> >>
> >> -Gautam
> >>
> >>
> >>
> >> On Wed, Sep 27, 2017 at 11:09 PM, Chris Olivier 
> >> wrote:
> >>
> >> > What does that mean? "Protected"? Protected from what?
> >> >
> >> > On Wed, Sep 27, 2017 at 11:08 PM Gautam  wrote:
> >> >
> >> > > Hi Chris,
> >> > >
> >> > >I mean make "master branch protected" of  MXNet.
> >> > >
> >> > > -Gautam
> >> > >
> >> > > On Wed, Sep 27, 2017 at 11:04 PM, Chris Olivier <
> cjolivie...@gmail.com
> >> >
> >> > > wrote:
> >> > >
> >> > > > What does this mean? "Mx-net branch protected"?
> >> > > >
> >> > > > On Wed, Sep 27, 2017 at 9:59 PM Tsuyoshi OZAWA <
> >> > ozawa.tsuyo...@gmail.com
> >> > > >
> >> > > > wrote:
> >> > > >
> >> > > > > +1,
> >> > > > >
> >> > > > > While I'm checking the recent build failures, and I think the
> >> > decision
> >> > > > > of making the mx-net branch protected is necessary for stable
> >> > > > > building.
> >> > > > > Thanks Kumar for resuming important discussion.
> >> > > > >
> >> > > > > Best regards
> >> > > > > - Tsuyoshi
> >> > > > >
> >> > > > > On Thu, Sep 28, 2017 at 12:56 PM, Kumar, Gautam <
> ga...@amazon.com>
> >> > > > wrote:
> >> > > > > > Reviving the discussion.
> >> > > > > >
> >> > > > > > At this point of time we have couple of stable builds
> >> > > > > >
> >> > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> >> > > > incubator-mxnet/job/master/448/
> >> > > > > >
> >> > > > > https://builds.apache.org/view/Incubator%20Projects/job/
> >> > > > incubator-mxnet/job/master/449/
> >> > > > > >
> >> > > > > > Should we have a quick discussion or polling on making the
> mx-net
> >> > > > branch
> >> > > > > protected? If you still think we shouldn’t make it protected
> please
> >> > > > provide
> >> > > > > a reason to support your claim.
> >> > > > > >
> >> > > > > > Few of us have concern over Jenkin’s stability. If I look two
> >> weeks
> >> > > > > back, after upgrading Linux slave to g2.8x and new windows AMI,
> we
> >> > have
> >> > > > not
> >> > > > > seen any case where instance died due to high memory usage or
> any
> >> > > process
> >> > > > > got killed due to h

Re: Apache MXNet build failures are mostly valid - verify before merge

[Joern Kottmann]

At Apache OpenNLP we just established among committers that you check
that the status indicator is green before you merge,
and if it wasn't the case then we would ask the committer to take
responsibility and repair things. Works very well our build is never
broken.

We also strongly prefer if each PR gets reviewed by another committer.

Overall this works quite well. We don't use any of the protections
against merging, it is important that you can trust each of the
committers not to break things, if there are problems it is better to
resolve them with talking to each other, rather than enforcing green
status checks.

Jörn

On Thu, Sep 28, 2017 at 8:21 AM, Chris Olivier  wrote:
> +1 on that
>
> On Wed, Sep 27, 2017 at 11:15 PM Gautam  wrote:
>
>> Hi Chris,
>>
>>   Here  is
>> user
>> document on semantics of protected branch.
>> In short when a branch is protected following applies to that branch.
>>
>>- Can't be force pushed
>>- Can't be deleted
>>- Can't have changes merged into it until required status checks
>> pass
>>- Can't have changes merged into it until required reviews are approved
>><
>> https://help.github.com/articles/approving-a-pull-request-with-required-reviews
>> >
>>- Can't be edited or have files uploaded to it from the web
>>- Can't have changes merged into it until changes to files that
>> have a designated
>>code owner  have
>>been approved by that owner
>>
>>  I am sure many of us might not want to have all these but we can debate on
>> it. My main motive was to "*Can't have changes merged into it until
>> required status checks pass*"
>>
>>
>> -Gautam
>>
>>
>>
>> On Wed, Sep 27, 2017 at 11:09 PM, Chris Olivier 
>> wrote:
>>
>> > What does that mean? "Protected"? Protected from what?
>> >
>> > On Wed, Sep 27, 2017 at 11:08 PM Gautam  wrote:
>> >
>> > > Hi Chris,
>> > >
>> > >I mean make "master branch protected" of  MXNet.
>> > >
>> > > -Gautam
>> > >
>> > > On Wed, Sep 27, 2017 at 11:04 PM, Chris Olivier > >
>> > > wrote:
>> > >
>> > > > What does this mean? "Mx-net branch protected"?
>> > > >
>> > > > On Wed, Sep 27, 2017 at 9:59 PM Tsuyoshi OZAWA <
>> > ozawa.tsuyo...@gmail.com
>> > > >
>> > > > wrote:
>> > > >
>> > > > > +1,
>> > > > >
>> > > > > While I'm checking the recent build failures, and I think the
>> > decision
>> > > > > of making the mx-net branch protected is necessary for stable
>> > > > > building.
>> > > > > Thanks Kumar for resuming important discussion.
>> > > > >
>> > > > > Best regards
>> > > > > - Tsuyoshi
>> > > > >
>> > > > > On Thu, Sep 28, 2017 at 12:56 PM, Kumar, Gautam 
>> > > > wrote:
>> > > > > > Reviving the discussion.
>> > > > > >
>> > > > > > At this point of time we have couple of stable builds
>> > > > > >
>> > > > > https://builds.apache.org/view/Incubator%20Projects/job/
>> > > > incubator-mxnet/job/master/448/
>> > > > > >
>> > > > > https://builds.apache.org/view/Incubator%20Projects/job/
>> > > > incubator-mxnet/job/master/449/
>> > > > > >
>> > > > > > Should we have a quick discussion or polling on making the mx-net
>> > > > branch
>> > > > > protected? If you still think we shouldn’t make it protected please
>> > > > provide
>> > > > > a reason to support your claim.
>> > > > > >
>> > > > > > Few of us have concern over Jenkin’s stability. If I look two
>> weeks
>> > > > > back, after upgrading Linux slave to g2.8x and new windows AMI, we
>> > have
>> > > > not
>> > > > > seen any case where instance died due to high memory usage or any
>> > > process
>> > > > > got killed due to high cpu usage or any other issue with windows
>> > > slaves.
>> > > > > >
>> > > > > > Going forward we are also planning that if we add any new slave
>> we
>> > > will
>> > > > > not enable the main load immediately, but rather will do ‘test
>> build’
>> > > to
>> > > > > make sure that new slaves are not causing any infrastructure issue
>> > and
>> > > > > capable to perform as good as existing slaves.
>> > > > > >
>> > > > > > -Gautam
>> > > > > >
>> > > > > > On 8/31/17, 5:27 PM, "Lupesko, Hagay"  wrote:
>> > > > > >
>> > > > > > @madan looking into some failures – you’re right… there’s
>> > > multiple
>> > > > > issues going on, some of them intermittent, and we want to be able
>> to
>> > > > merge
>> > > > > fixes in.
>> > > > > > Agreed that we can wait with setting up protected mode until
>> > > build
>> > > > > stabilizes.
>> > > > > >
>> > > > > > On 8/31/17, 11:41, "Madan Jampani" 
>> > > > wrote:
>> > > > > >
>> > > > > > @hagay: we agree on the end state. I'm not too particular
>> > > about
>> > > > > how we get
>> > > > > > there. If you think enabling it now and fixes regression
>> > > later
>> > > > > is doable,
>> > > > > > I'm fine with. I see a bit of a chicken and egg problem.
>> We
>> > > >

Re: CI problems

[Joern Kottmann]

GitHub shows red warnings for PRs that didn't pass all the tests. You
should never merge PRs which are red, or not current anymore (this
could also be a red status indicator).
If the failing tests can't be resolved quickly it might be worth
splitting the tests between stable / unstable and have different
status indicators for these tests.
Then people can see easily if the PR is breaking the stable tests.

Jörn

On Wed, Sep 27, 2017 at 8:12 PM, Gautam  wrote:
> Hi Chris,
>
> There could be possibility that someone might have merged the changes
> without having all checks running, or overlooked the result. Currently we
> don't have any mechanism where git farm can reject such merge where CI/Unit
> test fails. I will try to explore any such possibilities. Meanwhile I would
> rather disable those fail tests with a git hub issue so that build can be
> clean for now. We can revisit those issue later.
>
>
>
>
> On Wed, Sep 27, 2017 at 11:02 AM, kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
>
>> I share in your frustration Chris. I've also spent a fair amount of time in
>> the past few days digging through console logs to try and see if there was
>> anything actionable.  I haven't noticed any tests that were failing
>> consistently, maybe you can post an issue with some specific tests?  For me
>> the larger issue is Sanity Check failures and segfaults at the end of test
>> runs (after all tests pass).  I'm assuming that people are working on the
>> Sanity Check issues.  If there's anything external contributors can do
>> please let us know.
>>
>> On Wed, Sep 27, 2017 at 5:48 PM, Chris Olivier 
>> wrote:
>>
>> > By the way, I am not referring to a few tests that are known to fail
>> 1%-10%
>> > or so of the time (ie test_batchnorm_training) and are being actively
>> > worked on. I am referring to tests that fail 100% of the time and are
>> still
>> > merged into master, and thus propagate to all branches when sync'd from
>> > master.
>> >
>> > On Wed, Sep 27, 2017 at 8:43 AM, Chris Olivier 
>> > wrote:
>> >
>> > > How are so many broken unit tests getting into master?  Is stuff being
>> > > merged without passing CI/unit testing?  I have been trying to get
>> three
>> > > PR's to build for over a week now.  Each time it's some broken test or
>> > > another that has nothing to do with my code changes.  It's extremely
>> > > frustrating -- I waste whole days on this, trying to figure out why my
>> > code
>> > > is breaking strange things only to realize later it's broken in all
>> > > branches.
>> > >
>> >
>>
>
>
>
> --
> Best Regards,
> Gautam Kumar

Re: Web site questions

[Seb Kiureghian]

Hi Henry,

1. Not sure where you see the 'generated by' text. Could you provide a link?

2/3. The redesign is live at /master. I'm working with Santhosh Karuhatty
to fix simple errors, and here

are
some of the merged PR's. Your suggestions
 are good ones,
although I was not aware of this separate repo for the website. Let's
tackle these - I'll comment on the issues you've created.

Seb

On Wed, Sep 27, 2017 at 11:17 PM, Henri Yandell  wrote:

> Looking at the website ( https://github.com/apache/incubator-mxnet-site ),
> I've some questions:
>
> 1) Do we really need jenkins constantly committing date updates for
> doxygen? Is there a way to stop that 'generated by' text including the
> date?
>
> 2) Who is working on the website? There are some top level issues (
> https://github.com/apache/incubator-mxnet-site/issues ) that need
> addressing. I'm happy to dive in and work on them, but wanted to check
> beforehand. It's useful dayjob wise for me to learn Sphinx :)
>
> 3) Seb - you mentioned you were working on contributing a redesign, could
> you elaborate on where things are (post the Sep 12 initial email)?
>
> Hen
>

Re: CI system seems to be using python3 for python2 builds

[Tsuyoshi Ozawa]

Hi Rahul,

Thanks for sharing the information and taking on the problem!
I will also try the option(using nosetests-2.7 in Jenkinsfile).

Regards,
- Tsuyoshi

On Thu, Sep 28, 2017 at 3:34 PM, Rahul Huilgol  wrote:
> Hi Gautam,
>
> I see that ‘nosetests’ is the command used to run python2 tests. It looks
> like that’s being mapped to use python3. I’ve checked that this is the case
> on my Ubuntu instance. I need to use ‘nosetests-2.7’ to use python2 for the
> tests. Please check if this fix works in the build environment
> (slave/docker container) as well.
>
> The PR you refer to only parallelized tests that were running one after the
> other, this command was being used even before that PR.
>
> Regards,
> Rahul
>
> On Wed, 27 Sep 2017 at 22:46 Gautam  wrote:
>
>> Hi Ozawa,
>>
>>   Thanks for follow up.
>>   Unfortunately I didn't get time to work on this today.
>>
>> However I have couple of points to mentions.
>> 1. Looks like this backtrace has been present since long time, since this
>> was not a test failure or build failure we never got notified about it.
>> Here
>> <
>> https://builds.apache.org/view/Incubator%20Projects/job/incubator-mxnet/job/master/448/consoleFull
>> >
>> is the recent build log where back trace is present but build succeeded.
>>
>> 2. I don't think the default version of python on Ubuntu is 3.0, I logged
>> into one of the apache slave and the default version of Python is 2.7.6
>>
>> 3. There has been slight change
>>  in Jenkins file
>> where
>> we tried to parallelize python2 and 3 test run. I am not sure if it
>> affects. I can probably scrub the build log and figure out if thats the
>> case.
>>
>>
>> Feel free to send the PR, if you have it ready.
>>
>>
>> -Gautam
>>
>>
>> On Wed, Sep 27, 2017 at 9:39 PM, Tsuyoshi Ozawa  wrote:
>>
>> > Hi Kumar,
>> >
>> > Thanks for looking into the issue. How is the progress of this problem?
>> > Shouldn't we call /usr/bin/env python2 or python2.7 in following
>> > source code instead of python since MXNet only supports python2
>> > currently?
>> > I think default version of python in Ubuntu is now python3, so it can
>> > cause the problem.
>> > If you have not yet done the work, I can create a PR for that in this
>> > weekend.
>> >
>> > ./python/mxnet/__init__.py:#!/usr/bin/env python
>> > ./python/mxnet/log.py:#!/usr/bin/env python
>> > ./tests/nightly/dist_lenet.py:#!/usr/bin/env python
>> > ./tests/nightly/dist_sync_kvstore.py:#!/usr/bin/env python
>> > ./tests/nightly/multi_lenet.py:#!/usr/bin/env python
>> > ./tests/nightly/test_kvstore.py:#!/usr/bin/env python
>> > ./tools/coreml/mxnet_coreml_converter.py:#!/usr/bin/env python
>> > ./tools/ipynb2md.py:#!/usr/bin/env python
>> > ./tools/kill-mxnet.py:#!/usr/bin/env python
>> > ./tools/launch.py:#!/usr/bin/env python
>> > ./tools/parse_log.py:#!/usr/bin/env python
>> >
>> > On Wed, Sep 27, 2017 at 5:39 PM, Sunderland, Kellen 
>> > wrote:
>> > > Many thanks Gautam.
>> > >
>> > > On 9/26/17, 8:37 PM, "Kumar, Gautam"  wrote:
>> > >
>> > > Hi Kellen,
>> > >
>> > >This issue has been happening since last 3-4 days along with few
>> > other test failure.
>> > > I am looking into it.
>> > >
>> > > -Gautam
>> > >
>> > > On 9/26/17, 7:45 AM, "Sunderland, Kellen" 
>> wrote:
>> > >
>> > > I’ve been noticing in a few failed builds that the stack trace
>> > indicates we’re actually running python 3.4 in the python 2 tests. I know
>> > the CI folks are working hard getting everything setup, is this a known
>> > issue for the CI team?
>> > >
>> > > For example: https://builds.apache.org/
>> > blue/organizations/jenkins/incubator-mxnet/detail/PR-8026/3/pipeline/281
>> > >
>> > > Steps Python2: MKLML-CPU
>> > >
>> > > StackTrace:
>> > > Stack trace returned 10 entries:
>> > > [bt] (0) /workspace/python/mxnet/../../lib/libmxnet.so(_
>> > ZN4dmlc15LogMessageFatalD1Ev+0x3c) [0x7fadb8999aac]
>> > > [bt] (1) /workspace/python/mxnet/../../lib/libmxnet.so(_
>> > ZN5mxnet7kvstore12KVStoreLocal12GroupKVPairsISt4pairIPNS_
>> >
>> 7NDArrayES4_EZNS1_19GroupKVPairsPullRspERKSt6vectorIiSaIiEERKS7_IS6_SaIS6_
>> >
>> EEPS9_PS7_ISD_SaISD_EEEUliRKS6_E_EEvSB_RKS7_IT_SaISN_EESG_PS7_ISP_SaISP_EERKT0_+0x56b)
>> > [0x7fadba32c01b]
>> > > [bt] (2) /workspace/python/mxnet/../../lib/libmxnet.so(_
>> > ZN5mxnet7kvstore12KVStoreLocal17PullRowSparseImplERKSt6vecto
>> > rIiSaIiEERKS2_ISt4pairIPNS_7NDArrayES8_ESaISA_EEi+0xa6) [0x7fadba32c856]
>> > > [bt] (3)
>> /workspace/python/mxnet/../../lib/libmxnet.so(MXKVStorePullRowSparse+0x245)
>> > [0x7fadba18f165]
>> > > [bt] (4)
>> /usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_call_unix64+0x4c)
>> > [0x7fadde26cadc]
>> > > [bt] (5) /usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_call+0x1fc)
>> > [0x7fadde26c40c]
>> > > [bt] (6) /usr/lib/python3.4/lib-dynload/_ctypes.cpython-34m-
>> > x86_64-linux-gnu.so(_ctypes_callproc+0x21d) [0x