Re: [DISCUSSION] Adding labels to PRs

[Marco de Abreu]

I think option 1 and 3 would be good in combination. Meaningful titles
should always be encouraged and adding a label during the merge process
should only be a matter of seconds.

I dislike option 2 because introduces an additional step, which also
requires creating an account for JIRA, into the PR-process. This could
discourage especially new people from creating PRs and in general are the
other two approaches more than enough. I don’t think somebody would like to
create a JIRA-ticket just because they’re submitting a PR to update some
documentation.

On Fri, Nov 10, 2017 at 2:26 AM, Suneel Marthi  wrote:

> When u create a Jira - the jira carries a label of 'New Feature', 'Bug',
> 'Task' etc..., there's no need to again label each PR individually as long
> as the Jira### is referenced in the PR.
>
>
>
> On Fri, Nov 10, 2017 at 4:13 AM, Meghna Baijal  >
> wrote:
>
> > Hello All,
> >
> > Currently, there is no process in place to identify the new features that
> > go into every release.  All the commits since the previous release are
> > manually parsed to find the important changes that go into the release
> > notes.
> >
> >
> > In order to improve this process, I want to start a discussion on the
> > following options -
> >
> > 1. *Better PR titles* - if possible, these should be good enough to be
> > picked as is into the release notes.
> >
> > 2. *JIRA Issues* - each commit should be tagged with an associated JIRA
> > issue. This issue should describe the problem. JIRA tickets can be used
> to
> > automate the generation of release notes.
> >
> > 3. *Adding Labels to the PRs/Commits* - There can be a set of 3-5 labels
> > such as ‘Bug-Fix’, ‘New Feature’, ‘Docs’, ‘Minor Change’ etc. Atleast
> those
> > PRs which are important and should be included in the release notes
> should
> > be labeled.
> > However, labels can only be added by those with write access to the repo.
> > So the committers will have to triage this label addition as they
> > review/merge the PRs.
> >
> >
> > Do you think these changes are feasible? Will they help? What other
> options
> > should be considered?
> >
> > Thanks,
> > Meghna Baijal
> >
>

Re: [VOTE] A Separate CI System for Apache MXNet (incubating)

[Chris Olivier]

+1 for 1) — Jenkins


On Thu, Nov 9, 2017 at 9:14 PM Naveen Swamy  wrote:

> +1 on 1)
>
> > On Nov 9, 2017, at 8:59 PM, Steffen Rochel 
> wrote:
> >
> > voting for [1]
> > We will need to setup testing on MAC. I will explore for AWS to cover the
> > costs.
> > Steffen
> >
> > On Thu, Nov 9, 2017 at 4:41 PM Meghna Baijal  >
> > wrote:
> >
> >> Hi All,
> >> A need has been identified for MXNet’s CI/CD setup to move away from the
> >> Apache Jenkins Service. Over the past few days there has been active
> >> discussion on the necessary and advanced features for such a system and
> the
> >> various options available. These are being tracked in this Google Doc
> >> <
> https://docs.google.com/document/d/17PEasQ2VWrXi2Cf7IGZSWGZMawxDkdlavUDASzUmLjk/edit>
> (and
> >> are also in the pdf attached).
> >>
> >> I would like to start a vote to choose the framework for this new CI/CD
> >> system. The options are -
> >> [1] Jenkins (A setup separated from Apache Jenkins) - with various
> plugins
> >> [2] TeamCity
> >> [3] Travis CI
> >> [4] GitLabCI
> >> [5] BuildBot
> >> [6] Other - Please Name
> >>
> >> Please feel free to add a comment to support your choice.
> >> This vote will be open from now until the end of the day on Monday
> >> 11/13/2017
> >>
> >> Thanks,
> >> Meghna Baijal
> >>
> >>
> >>
>

[BUILD FAILED] Branch master build 607

[Apache Jenkins Server]

Build for MXNet branch master has broken. Please view the build at 
https://builds.apache.org/job/incubator-mxnet/job/master/607/

Re: [VOTE] A Separate CI System for Apache MXNet (incubating)

[Naveen Swamy]

+1 on 1)

> On Nov 9, 2017, at 8:59 PM, Steffen Rochel  wrote:
> 
> voting for [1]
> We will need to setup testing on MAC. I will explore for AWS to cover the
> costs.
> Steffen
> 
> On Thu, Nov 9, 2017 at 4:41 PM Meghna Baijal 
> wrote:
> 
>> Hi All,
>> A need has been identified for MXNet’s CI/CD setup to move away from the
>> Apache Jenkins Service. Over the past few days there has been active
>> discussion on the necessary and advanced features for such a system and the
>> various options available. These are being tracked in this Google Doc
>> 
>>  (and
>> are also in the pdf attached).
>> 
>> I would like to start a vote to choose the framework for this new CI/CD
>> system. The options are -
>> [1] Jenkins (A setup separated from Apache Jenkins) - with various plugins
>> [2] TeamCity
>> [3] Travis CI
>> [4] GitLabCI
>> [5] BuildBot
>> [6] Other - Please Name
>> 
>> Please feel free to add a comment to support your choice.
>> This vote will be open from now until the end of the day on Monday
>> 11/13/2017
>> 
>> Thanks,
>> Meghna Baijal
>> 
>> 
>> 

Re: [VOTE] A Separate CI System for Apache MXNet (incubating)

[Steffen Rochel]

voting for [1]
We will need to setup testing on MAC. I will explore for AWS to cover the
costs.
Steffen

On Thu, Nov 9, 2017 at 4:41 PM Meghna Baijal 
wrote:

> Hi All,
> A need has been identified for MXNet’s CI/CD setup to move away from the
> Apache Jenkins Service. Over the past few days there has been active
> discussion on the necessary and advanced features for such a system and the
> various options available. These are being tracked in this Google Doc
> 
>  (and
> are also in the pdf attached).
>
> I would like to start a vote to choose the framework for this new CI/CD
> system. The options are -
> [1] Jenkins (A setup separated from Apache Jenkins) - with various plugins
> [2] TeamCity
> [3] Travis CI
> [4] GitLabCI
> [5] BuildBot
> [6] Other - Please Name
>
> Please feel free to add a comment to support your choice.
> This vote will be open from now until the end of the day on Monday
> 11/13/2017
>
> Thanks,
> Meghna Baijal
>
>
>

Re: [DISCUSSION] Adding labels to PRs

[Suneel Marthi]

When u create a Jira - the jira carries a label of 'New Feature', 'Bug',
'Task' etc..., there's no need to again label each PR individually as long
as the Jira### is referenced in the PR.



On Fri, Nov 10, 2017 at 4:13 AM, Meghna Baijal 
wrote:

> Hello All,
>
> Currently, there is no process in place to identify the new features that
> go into every release.  All the commits since the previous release are
> manually parsed to find the important changes that go into the release
> notes.
>
>
> In order to improve this process, I want to start a discussion on the
> following options -
>
> 1. *Better PR titles* - if possible, these should be good enough to be
> picked as is into the release notes.
>
> 2. *JIRA Issues* - each commit should be tagged with an associated JIRA
> issue. This issue should describe the problem. JIRA tickets can be used to
> automate the generation of release notes.
>
> 3. *Adding Labels to the PRs/Commits* - There can be a set of 3-5 labels
> such as ‘Bug-Fix’, ‘New Feature’, ‘Docs’, ‘Minor Change’ etc. Atleast those
> PRs which are important and should be included in the release notes should
> be labeled.
> However, labels can only be added by those with write access to the repo.
> So the committers will have to triage this label addition as they
> review/merge the PRs.
>
>
> Do you think these changes are feasible? Will they help? What other options
> should be considered?
>
> Thanks,
> Meghna Baijal
>

Re: [DISCUSSION] Adding labels to PRs

[madan jampani]

I really like (2). Yes it is work to link each PR to a Jira. But it really 
helps users understand what they are getting. The Jira can contain the 
necessary context.

Spark does this well: https://github.com/apache/spark/commits/master

Madan

> On Nov 9, 2017, at 2:43 PM, Meghna Baijal  wrote:
> 
> Hello All,
> 
> Currently, there is no process in place to identify the new features that
> go into every release.  All the commits since the previous release are
> manually parsed to find the important changes that go into the release
> notes.
> 
> 
> In order to improve this process, I want to start a discussion on the
> following options -
> 
> 1. *Better PR titles* - if possible, these should be good enough to be
> picked as is into the release notes.
> 
> 2. *JIRA Issues* - each commit should be tagged with an associated JIRA
> issue. This issue should describe the problem. JIRA tickets can be used to
> automate the generation of release notes.
> 
> 3. *Adding Labels to the PRs/Commits* - There can be a set of 3-5 labels
> such as ‘Bug-Fix’, ‘New Feature’, ‘Docs’, ‘Minor Change’ etc. Atleast those
> PRs which are important and should be included in the release notes should
> be labeled.
> However, labels can only be added by those with write access to the repo.
> So the committers will have to triage this label addition as they
> review/merge the PRs.
> 
> 
> Do you think these changes are feasible? Will they help? What other options
> should be considered?
> 
> Thanks,
> Meghna Baijal

[VOTE] A Separate CI System for Apache MXNet (incubating)

[Meghna Baijal]

Hi All,
A need has been identified for MXNet’s CI/CD setup to move away from the
Apache Jenkins Service. Over the past few days there has been active
discussion on the necessary and advanced features for such a system and the
various options available. These are being tracked in this Google Doc

(and
are also in the pdf attached).

I would like to start a vote to choose the framework for this new CI/CD
system. The options are -
[1] Jenkins (A setup separated from Apache Jenkins) - with various plugins
[2] TeamCity
[3] Travis CI
[4] GitLabCI
[5] BuildBot
[6] Other - Please Name

Please feel free to add a comment to support your choice.
This vote will be open from now until the end of the day on Monday
11/13/2017

Thanks,
Meghna Baijal

Re: [Proposal] Stabilizing Apache MXNet CI build system

[Meghna Baijal]

Chris,
The Windows slaves on apache use EIPs which makes it easier to
replace/reboot/reconnect these instances. But, there are some reasons
because of which EIPs cannot be used for ubuntu slaves
Several workarounds are being explored for this. And one such solution is
to use the aws codebuild plugin with Jenkins -

1. In Jenkins there is a plugin to integrate with aws codebuild which can
be used to automate slave management.
2. The idea is to configure only the *ubuntu* slaves using this plugin.
This addresses the issue of EIPs and automation on ubuntu.
3. Other platforms such as windows and Edge devices continue to be
configured directly through jenkins without using this plugin. This is ok
since windows slaves anyway use EIPs

At this point this is only in POC stage.

Thanks,
Meghna Baijal

On Thu, Nov 9, 2017 at 12:23 PM, Meghna Baijal 
wrote:

> Pedro, I created a row for BuildBot in the doc. Do you want to add some
> pros and cons about it? It would be good to have all this information
> collected in one place.
>
> Meghna
>
> On Thu, Nov 9, 2017 at 4:40 AM, Larroy, Pedro  wrote:
>
>> Thanks a lot for the document and leading the discussion.
>>
>> Does anybody have experience with a build system other than Jenkins? In
>> the document we mention Teamcity as a possible option, and there’s also the
>> second leading open source CI tool “Buildbot” which is not mentioned.
>>
>> I’m not sure if we have strong evidence to have an informed decision
>> about using something other than Jenkins, also from the document I get that
>> the negatives of Jenkins are pretty minor compared to the other frameworks.
>>
>> I would be interested to read if somebody has used any other framework in
>> depth and is willing to vote against using Jenkins so we can all do an
>> informed vote.
>>
>> I don’t feel comfortable voting for Jenkins because is the only one I
>> know as well.
>>
>> Kind regards.
>> --
>>
>> Pedro
>>
>> On 08/11/17 23:41, "Meghna Baijal"  wrote:
>>
>> Thanks for the active discussion on the document for the new CI for
>> MXNet.
>> Now that many of you have reviewed it, do you think I should start a
>> vote
>> on which framework the community wants to move forward with ?
>>
>> Thanks,
>> Meghna
>>
>> On Mon, Nov 6, 2017 at 6:59 PM, Chris Olivier 
>> wrote:
>>
>> > After a decision is reached, i am willing to add tasks to Apache
>> MXNet JIRA
>> >
>> > On Mon, Nov 6, 2017 at 6:15 AM, Pedro Larroy <
>> pedro.larroy.li...@gmail.com
>> > >
>> > wrote:
>> >
>> > > Thanks for setting up the document guys, looks like a solid basis
>> to
>> > > start to work on!
>> > >
>> > > Marco, Kellen and I have already added some comments.
>> > >
>> > > Pedro
>> > >
>> > >
>> > > On Sun, Nov 5, 2017 at 3:43 AM, Meghna Baijal
>> > >  wrote:
>> > > > Kellen, Thank you for your comments in the doc.
>> > > > Sure Steffen, I will continue to merge everyone’s comments into
>> the doc
>> > > and
>> > > > work with Pedro to finalize it.
>> > > > And then we can vote on the options.
>> > > >
>> > > > Thanks,
>> > > > Meghna Baijal
>> > > >
>> > > >
>> > > > On Sat, Nov 4, 2017 at 6:34 AM, Steffen Rochel <
>> > steffenroc...@gmail.com>
>> > > > wrote:
>> > > >
>> > > >> Sandeep and Meghna have been working in background collecting
>> input
>> > and
>> > > >> preparing a doc. I suggest to drive discussion forward and
>> would like
>> > to
>> > > >> ask everybody to contribute to
>> > > >> https://docs.google.com/document/d/17PEasQ2VWrXi2Cf7IGZSWGZM
>> awxDk
>> > > >> dlavUDASzUmLjk/edit?usp=sharing
>> > > >>
>> > > >> Lets converge on requirements and architecture, so we can move
>> forward
>> > > with
>> > > >> implementation.
>> > > >>
>> > > >> I would like to suggest for Pedro  and Meghna to lead the
>> discussion
>> > and
>> > > >> help to resolve suggestions.
>> > > >>
>> > > >> I assume we need a vote once we are converged on a good draft
>> to call
>> > > it a
>> > > >> plan and move forward with implementation. As we all are
>> unhappy with
>> > > the
>> > > >> current CI situation I would also suggest a phased approach,
>> so we can
>> > > get
>> > > >> back to reliable and efficient basic CI quickly and add
>> advanced
>> > > >> capabilities over time.
>> > > >>
>> > > >> Steffen
>> > > >>
>> > > >> On Wed, Nov 1, 2017 at 1:14 PM kellen sunderland <
>> > > >> kellen.sunderl...@gmail.com> wrote:
>> > > >>
>> > > >> > Hey Henri, I think that's what a few of us are advocating.
>> Running
>> > a
>> > > set
>> > > >> > of quick tests as part of the PR process, and then a more
>> detailed
>> > > >> > regression test suite 

[DISCUSSION] Adding labels to PRs

[Meghna Baijal]

Hello All,

Currently, there is no process in place to identify the new features that
go into every release.  All the commits since the previous release are
manually parsed to find the important changes that go into the release
notes.


In order to improve this process, I want to start a discussion on the
following options -

1. *Better PR titles* - if possible, these should be good enough to be
picked as is into the release notes.

2. *JIRA Issues* - each commit should be tagged with an associated JIRA
issue. This issue should describe the problem. JIRA tickets can be used to
automate the generation of release notes.

3. *Adding Labels to the PRs/Commits* - There can be a set of 3-5 labels
such as ‘Bug-Fix’, ‘New Feature’, ‘Docs’, ‘Minor Change’ etc. Atleast those
PRs which are important and should be included in the release notes should
be labeled.
However, labels can only be added by those with write access to the repo.
So the committers will have to triage this label addition as they
review/merge the PRs.


Do you think these changes are feasible? Will they help? What other options
should be considered?

Thanks,
Meghna Baijal

Re: [Proposal] Stabilizing Apache MXNet CI build system

[Meghna Baijal]

Pedro, I created a row for BuildBot in the doc. Do you want to add some
pros and cons about it? It would be good to have all this information
collected in one place.

Meghna

On Thu, Nov 9, 2017 at 4:40 AM, Larroy, Pedro  wrote:

> Thanks a lot for the document and leading the discussion.
>
> Does anybody have experience with a build system other than Jenkins? In
> the document we mention Teamcity as a possible option, and there’s also the
> second leading open source CI tool “Buildbot” which is not mentioned.
>
> I’m not sure if we have strong evidence to have an informed decision about
> using something other than Jenkins, also from the document I get that the
> negatives of Jenkins are pretty minor compared to the other frameworks.
>
> I would be interested to read if somebody has used any other framework in
> depth and is willing to vote against using Jenkins so we can all do an
> informed vote.
>
> I don’t feel comfortable voting for Jenkins because is the only one I know
> as well.
>
> Kind regards.
> --
>
> Pedro
>
> On 08/11/17 23:41, "Meghna Baijal"  wrote:
>
> Thanks for the active discussion on the document for the new CI for
> MXNet.
> Now that many of you have reviewed it, do you think I should start a
> vote
> on which framework the community wants to move forward with ?
>
> Thanks,
> Meghna
>
> On Mon, Nov 6, 2017 at 6:59 PM, Chris Olivier 
> wrote:
>
> > After a decision is reached, i am willing to add tasks to Apache
> MXNet JIRA
> >
> > On Mon, Nov 6, 2017 at 6:15 AM, Pedro Larroy <
> pedro.larroy.li...@gmail.com
> > >
> > wrote:
> >
> > > Thanks for setting up the document guys, looks like a solid basis
> to
> > > start to work on!
> > >
> > > Marco, Kellen and I have already added some comments.
> > >
> > > Pedro
> > >
> > >
> > > On Sun, Nov 5, 2017 at 3:43 AM, Meghna Baijal
> > >  wrote:
> > > > Kellen, Thank you for your comments in the doc.
> > > > Sure Steffen, I will continue to merge everyone’s comments into
> the doc
> > > and
> > > > work with Pedro to finalize it.
> > > > And then we can vote on the options.
> > > >
> > > > Thanks,
> > > > Meghna Baijal
> > > >
> > > >
> > > > On Sat, Nov 4, 2017 at 6:34 AM, Steffen Rochel <
> > steffenroc...@gmail.com>
> > > > wrote:
> > > >
> > > >> Sandeep and Meghna have been working in background collecting
> input
> > and
> > > >> preparing a doc. I suggest to drive discussion forward and
> would like
> > to
> > > >> ask everybody to contribute to
> > > >> https://docs.google.com/document/d/
> 17PEasQ2VWrXi2Cf7IGZSWGZMawxDk
> > > >> dlavUDASzUmLjk/edit?usp=sharing
> > > >>
> > > >> Lets converge on requirements and architecture, so we can move
> forward
> > > with
> > > >> implementation.
> > > >>
> > > >> I would like to suggest for Pedro  and Meghna to lead the
> discussion
> > and
> > > >> help to resolve suggestions.
> > > >>
> > > >> I assume we need a vote once we are converged on a good draft
> to call
> > > it a
> > > >> plan and move forward with implementation. As we all are
> unhappy with
> > > the
> > > >> current CI situation I would also suggest a phased approach, so
> we can
> > > get
> > > >> back to reliable and efficient basic CI quickly and add advanced
> > > >> capabilities over time.
> > > >>
> > > >> Steffen
> > > >>
> > > >> On Wed, Nov 1, 2017 at 1:14 PM kellen sunderland <
> > > >> kellen.sunderl...@gmail.com> wrote:
> > > >>
> > > >> > Hey Henri, I think that's what a few of us are advocating.
> Running
> > a
> > > set
> > > >> > of quick tests as part of the PR process, and then a more
> detailed
> > > >> > regression test suite periodically (say every 4 hours). This
> fits
> > > nicely
> > > >> > into a tagging or 2 branch development system.  Commits will
> be
> > tagged
> > > >> (or
> > > >> > merged into a stable branch) as soon as they pass the detailed
> > > regression
> > > >> > testing.
> > > >> >
> > > >> > On Wed, Nov 1, 2017 at 9:07 PM, Hen 
> wrote:
> > > >> >
> > > >> > > Random question - can the CI be split such that the Apache
> CI is
> > > doing
> > > >> a
> > > >> > > basic set of checks on that hardware, and is hooked to a
> PR, while
> > > >> there
> > > >> > is
> > > >> > > a larger "Is trunk good for release?" test that is running
> > > periodically
> > > >> > > rather than on every PR?
> > > >> > >
> > > >> > > ie: do we need each PR to be run on varied hardware, or can
> we
> > have
> > > >> this
> > > >> > > two tier approach?
> > > >> > >
> > > >> > > Hen
> > > >> > >
> > > >> > > 

Re: [Proposal] Stabilizing Apache MXNet CI build system

[Larroy, Pedro]

Thanks a lot for the document and leading the discussion.

Does anybody have experience with a build system other than Jenkins? In the 
document we mention Teamcity as a possible option, and there’s also the second 
leading open source CI tool “Buildbot” which is not mentioned.

I’m not sure if we have strong evidence to have an informed decision about 
using something other than Jenkins, also from the document I get that the 
negatives of Jenkins are pretty minor compared to the other frameworks.

I would be interested to read if somebody has used any other framework in depth 
and is willing to vote against using Jenkins so we can all do an informed vote.

I don’t feel comfortable voting for Jenkins because is the only one I know as 
well.

Kind regards.
-- 

Pedro

On 08/11/17 23:41, "Meghna Baijal"  wrote:

Thanks for the active discussion on the document for the new CI for MXNet.
Now that many of you have reviewed it, do you think I should start a vote
on which framework the community wants to move forward with ?

Thanks,
Meghna

On Mon, Nov 6, 2017 at 6:59 PM, Chris Olivier  wrote:

> After a decision is reached, i am willing to add tasks to Apache MXNet 
JIRA
>
> On Mon, Nov 6, 2017 at 6:15 AM, Pedro Larroy  >
> wrote:
>
> > Thanks for setting up the document guys, looks like a solid basis to
> > start to work on!
> >
> > Marco, Kellen and I have already added some comments.
> >
> > Pedro
> >
> >
> > On Sun, Nov 5, 2017 at 3:43 AM, Meghna Baijal
> >  wrote:
> > > Kellen, Thank you for your comments in the doc.
> > > Sure Steffen, I will continue to merge everyone’s comments into the 
doc
> > and
> > > work with Pedro to finalize it.
> > > And then we can vote on the options.
> > >
> > > Thanks,
> > > Meghna Baijal
> > >
> > >
> > > On Sat, Nov 4, 2017 at 6:34 AM, Steffen Rochel <
> steffenroc...@gmail.com>
> > > wrote:
> > >
> > >> Sandeep and Meghna have been working in background collecting input
> and
> > >> preparing a doc. I suggest to drive discussion forward and would like
> to
> > >> ask everybody to contribute to
> > >> https://docs.google.com/document/d/17PEasQ2VWrXi2Cf7IGZSWGZMawxDk
> > >> dlavUDASzUmLjk/edit?usp=sharing
> > >>
> > >> Lets converge on requirements and architecture, so we can move 
forward
> > with
> > >> implementation.
> > >>
> > >> I would like to suggest for Pedro  and Meghna to lead the discussion
> and
> > >> help to resolve suggestions.
> > >>
> > >> I assume we need a vote once we are converged on a good draft to call
> > it a
> > >> plan and move forward with implementation. As we all are unhappy with
> > the
> > >> current CI situation I would also suggest a phased approach, so we 
can
> > get
> > >> back to reliable and efficient basic CI quickly and add advanced
> > >> capabilities over time.
> > >>
> > >> Steffen
> > >>
> > >> On Wed, Nov 1, 2017 at 1:14 PM kellen sunderland <
> > >> kellen.sunderl...@gmail.com> wrote:
> > >>
> > >> > Hey Henri, I think that's what a few of us are advocating.  Running
> a
> > set
> > >> > of quick tests as part of the PR process, and then a more detailed
> > >> > regression test suite periodically (say every 4 hours). This fits
> > nicely
> > >> > into a tagging or 2 branch development system.  Commits will be
> tagged
> > >> (or
> > >> > merged into a stable branch) as soon as they pass the detailed
> > regression
> > >> > testing.
> > >> >
> > >> > On Wed, Nov 1, 2017 at 9:07 PM, Hen  wrote:
> > >> >
> > >> > > Random question - can the CI be split such that the Apache CI is
> > doing
> > >> a
> > >> > > basic set of checks on that hardware, and is hooked to a PR, 
while
> > >> there
> > >> > is
> > >> > > a larger "Is trunk good for release?" test that is running
> > periodically
> > >> > > rather than on every PR?
> > >> > >
> > >> > > ie: do we need each PR to be run on varied hardware, or can we
> have
> > >> this
> > >> > > two tier approach?
> > >> > >
> > >> > > Hen
> > >> > >
> > >> > > On Fri, Oct 20, 2017 at 1:01 PM, sandeep krishnamurthy <
> > >> > > sandeep.krishn...@gmail.com> wrote:
> > >> > >
> > >> > > > Hello all,
> > >> > > >
> > >> > > > I am hereby opening up a discussion thread on how we can
> stabilize
> > >> > Apache
> > >> > > > MXNet CI build system.
> > >> > > >
> > >> > > > Problems:
> > >> > > >
> > >> > > > 
> > >> > > >
> > >> > > > Recently, we have seen following issues with Apache MXNet CI
> build