Re: MXNet: Run PR builds on Apache Jenkins only after the commit is reviewed

[Lin, Haibin]

Also +1 on this. 

Haibin

On 9/12/17, 9:28 PM, "Chris Olivier"  wrote:

+1 to this

On Tue, Sep 12, 2017 at 8:48 PM Bhavin Thaker 
wrote:

> My vote is to make the CI build and test process lightweight and efficient
> and not involve a human to give a go-ahead for a PR build.
>
> There are multiple ways to engineer a stable and efficient CI system,
> (already discussed on this email thread), including canceling previously
> running build for a particular PR before invoking a new build, using
> Incredibuild, adding more machines to CI, etc.
>
> In short, as we scale to many engineers working on MXNet around the globe
> in different time-zones, precious human involvement should be minimal and
> be used judiciously only for critical things like code-review and only
> after sufficient amount of sanity build-tests have passed.
>
> Let the machines work harder for humans and not the other way around.
>
> Bhavin Thaker.
>
> On Tue, Sep 12, 2017 at 12:20 PM Chris Olivier 
> wrote:
>
> > The majority of these iterations is to trigger a build on the broken CI
> in
> > hopes it will finally pass...
> >
> > On Tue, Sep 12, 2017 at 11:15 AM Madan Jampani 
> > wrote:
> >
> > > +1
> > > I second only running sanity test (lint) until manual approval.
> > >
> > > On Tue, Sep 12, 2017 at 11:05 AM, Naveen Swamy 
> > wrote:
> > >
> > > > Just to be clear, the proposal is not to remove the PR build. It's
> only
> > > to
> > > > delay the PR build until a reviewer has looked at it and marks it
> > > Approved
> > > > or adds a Label to build. Once it's approved and PR build succeeds a
> > > > reviewer/committer can see the build result and merge to the master.
> > > >
> > > > I don't mean to pick on the author of this PR(Chris), I am just 
using
> > > this
> > > > build to support my argument.
> > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > incubator-mxnet/view/change-requests/job/PR-7577/
> > > >  This has gone through 74 iterations, I understand not all of them
> are
> > > due
> > > > to changes and some of them are due to build instability and some
> dummy
> > > > commits to getting the PR build to pass. However, the PR has been
> under
> > > > review and changes being made for the last several days. I don't
> think
> > it
> > > > warrants a build trigger for every new change. Each build on average
> > > takes
> > > > about 2 hours running on all platforms.
> > > >
> > > > Probably we can run a lean down version of the current PR build 
where
> > we
> > > > have sanity-test(lint)->build on linux(cpu)->unit test on linux(cpu)
> ?
> > > >
> > > >
> > > > Thanks, Naveen
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Sep 12, 2017 at 4:27 AM, Joern Kottmann 
> > > > wrote:
> > > >
> > > > > Not sure how it works with jenkins, but other CI serves can look 
at
> > > > > the commit message and skip the CI run based on certain commands 
in
> > > > > it.
> > > > >
> > > > > Might make sense for small changes such as documentation updates,
> > half
> > > > > done PRs, etc.
> > > > >
> > > > > Jörn
> > > > >
> > > > > On Tue, Sep 12, 2017 at 11:17 AM, Larroy, Pedro <
> pllar...@amazon.de>
> > > > > wrote:
> > > > > > Hi
> > > > > >
> > > > > > I would like to integrate our CI system for devices to make sure
> > PRs
> > > > > build on ARM / android etc. Who has admin rights on the repository
> so
> > > we
> > > > > can install the necessary hooks to trigger our builds?
> > > > > >
> > > > > >
> > > > > > Kind regards.
> > > > > > --
> > > > > >
> > > > > > Pedro
> > > > > >
> > > > > > On 12/09/17 02:50, "Meghna Baijal" 
> > > wrote:
> > > > > >
> > > > > > Hi All,
> > > > > > We would like to initiate a change in the way the PR builds
> are
> > > > > being triggered. At the moment, every time a Pull Request is
> > created, a
> > > > > build gets triggered on Jenkins. Additional builds also get
> triggered
> > > due
> > > > > to changes to the same PR.
> > > > > > Too many PR builds leads to resource starvation and very 
long
> > > > queues
> > > > > and long build times. Hence we would like to add some checks where
> a
> > > > human
> > > > > reviewer manually marks it to something like “ok to build” before 
a
> > PR
> > > > > build is triggered.
> > > > > >
> > > > > > Do you think this approach would be helpful and we should
  

Re: MXNet: Run PR builds on Apache Jenkins only after the commit is reviewed

[Chris Olivier]

+1 to this

On Tue, Sep 12, 2017 at 8:48 PM Bhavin Thaker 
wrote:

> My vote is to make the CI build and test process lightweight and efficient
> and not involve a human to give a go-ahead for a PR build.
>
> There are multiple ways to engineer a stable and efficient CI system,
> (already discussed on this email thread), including canceling previously
> running build for a particular PR before invoking a new build, using
> Incredibuild, adding more machines to CI, etc.
>
> In short, as we scale to many engineers working on MXNet around the globe
> in different time-zones, precious human involvement should be minimal and
> be used judiciously only for critical things like code-review and only
> after sufficient amount of sanity build-tests have passed.
>
> Let the machines work harder for humans and not the other way around.
>
> Bhavin Thaker.
>
> On Tue, Sep 12, 2017 at 12:20 PM Chris Olivier 
> wrote:
>
> > The majority of these iterations is to trigger a build on the broken CI
> in
> > hopes it will finally pass...
> >
> > On Tue, Sep 12, 2017 at 11:15 AM Madan Jampani 
> > wrote:
> >
> > > +1
> > > I second only running sanity test (lint) until manual approval.
> > >
> > > On Tue, Sep 12, 2017 at 11:05 AM, Naveen Swamy 
> > wrote:
> > >
> > > > Just to be clear, the proposal is not to remove the PR build. It's
> only
> > > to
> > > > delay the PR build until a reviewer has looked at it and marks it
> > > Approved
> > > > or adds a Label to build. Once it's approved and PR build succeeds a
> > > > reviewer/committer can see the build result and merge to the master.
> > > >
> > > > I don't mean to pick on the author of this PR(Chris), I am just using
> > > this
> > > > build to support my argument.
> > > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > > incubator-mxnet/view/change-requests/job/PR-7577/
> > > >  This has gone through 74 iterations, I understand not all of them
> are
> > > due
> > > > to changes and some of them are due to build instability and some
> dummy
> > > > commits to getting the PR build to pass. However, the PR has been
> under
> > > > review and changes being made for the last several days. I don't
> think
> > it
> > > > warrants a build trigger for every new change. Each build on average
> > > takes
> > > > about 2 hours running on all platforms.
> > > >
> > > > Probably we can run a lean down version of the current PR build where
> > we
> > > > have sanity-test(lint)->build on linux(cpu)->unit test on linux(cpu)
> ?
> > > >
> > > >
> > > > Thanks, Naveen
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Sep 12, 2017 at 4:27 AM, Joern Kottmann 
> > > > wrote:
> > > >
> > > > > Not sure how it works with jenkins, but other CI serves can look at
> > > > > the commit message and skip the CI run based on certain commands in
> > > > > it.
> > > > >
> > > > > Might make sense for small changes such as documentation updates,
> > half
> > > > > done PRs, etc.
> > > > >
> > > > > Jörn
> > > > >
> > > > > On Tue, Sep 12, 2017 at 11:17 AM, Larroy, Pedro <
> pllar...@amazon.de>
> > > > > wrote:
> > > > > > Hi
> > > > > >
> > > > > > I would like to integrate our CI system for devices to make sure
> > PRs
> > > > > build on ARM / android etc. Who has admin rights on the repository
> so
> > > we
> > > > > can install the necessary hooks to trigger our builds?
> > > > > >
> > > > > >
> > > > > > Kind regards.
> > > > > > --
> > > > > >
> > > > > > Pedro
> > > > > >
> > > > > > On 12/09/17 02:50, "Meghna Baijal" 
> > > wrote:
> > > > > >
> > > > > > Hi All,
> > > > > > We would like to initiate a change in the way the PR builds
> are
> > > > > being triggered. At the moment, every time a Pull Request is
> > created, a
> > > > > build gets triggered on Jenkins. Additional builds also get
> triggered
> > > due
> > > > > to changes to the same PR.
> > > > > > Too many PR builds leads to resource starvation and very long
> > > > queues
> > > > > and long build times. Hence we would like to add some checks where
> a
> > > > human
> > > > > reviewer manually marks it to something like “ok to build” before a
> > PR
> > > > > build is triggered.
> > > > > >
> > > > > > Do you think this approach would be helpful and we should
> move
> > > > > forward with it?
> > > > > >
> > > > > > Thanks,
> > > > > > Meghna Baijal
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Amazon Development Center Germany GmbH
> > > > > > Berlin - Dresden - Aachen
> > > > > > main office: Krausenstr. 38, 10117 Berlin
> > > > > > Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
> > > > > > Ust-ID: DE289237879
> > > > > > Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
> > > > >
> > > >
> > >
> >
>

Re: MXNet: Run PR builds on Apache Jenkins only after the commit is reviewed

[Bhavin Thaker]

My vote is to make the CI build and test process lightweight and efficient
and not involve a human to give a go-ahead for a PR build.

There are multiple ways to engineer a stable and efficient CI system,
(already discussed on this email thread), including canceling previously
running build for a particular PR before invoking a new build, using
Incredibuild, adding more machines to CI, etc.

In short, as we scale to many engineers working on MXNet around the globe
in different time-zones, precious human involvement should be minimal and
be used judiciously only for critical things like code-review and only
after sufficient amount of sanity build-tests have passed.

Let the machines work harder for humans and not the other way around.

Bhavin Thaker.

On Tue, Sep 12, 2017 at 12:20 PM Chris Olivier 
wrote:

> The majority of these iterations is to trigger a build on the broken CI in
> hopes it will finally pass...
>
> On Tue, Sep 12, 2017 at 11:15 AM Madan Jampani 
> wrote:
>
> > +1
> > I second only running sanity test (lint) until manual approval.
> >
> > On Tue, Sep 12, 2017 at 11:05 AM, Naveen Swamy 
> wrote:
> >
> > > Just to be clear, the proposal is not to remove the PR build. It's only
> > to
> > > delay the PR build until a reviewer has looked at it and marks it
> > Approved
> > > or adds a Label to build. Once it's approved and PR build succeeds a
> > > reviewer/committer can see the build result and merge to the master.
> > >
> > > I don't mean to pick on the author of this PR(Chris), I am just using
> > this
> > > build to support my argument.
> > > https://builds.apache.org/view/Incubator%20Projects/job/
> > > incubator-mxnet/view/change-requests/job/PR-7577/
> > >  This has gone through 74 iterations, I understand not all of them are
> > due
> > > to changes and some of them are due to build instability and some dummy
> > > commits to getting the PR build to pass. However, the PR has been under
> > > review and changes being made for the last several days. I don't think
> it
> > > warrants a build trigger for every new change. Each build on average
> > takes
> > > about 2 hours running on all platforms.
> > >
> > > Probably we can run a lean down version of the current PR build where
> we
> > > have sanity-test(lint)->build on linux(cpu)->unit test on linux(cpu) ?
> > >
> > >
> > > Thanks, Naveen
> > >
> > >
> > >
> > >
> > > On Tue, Sep 12, 2017 at 4:27 AM, Joern Kottmann 
> > > wrote:
> > >
> > > > Not sure how it works with jenkins, but other CI serves can look at
> > > > the commit message and skip the CI run based on certain commands in
> > > > it.
> > > >
> > > > Might make sense for small changes such as documentation updates,
> half
> > > > done PRs, etc.
> > > >
> > > > Jörn
> > > >
> > > > On Tue, Sep 12, 2017 at 11:17 AM, Larroy, Pedro 
> > > > wrote:
> > > > > Hi
> > > > >
> > > > > I would like to integrate our CI system for devices to make sure
> PRs
> > > > build on ARM / android etc. Who has admin rights on the repository so
> > we
> > > > can install the necessary hooks to trigger our builds?
> > > > >
> > > > >
> > > > > Kind regards.
> > > > > --
> > > > >
> > > > > Pedro
> > > > >
> > > > > On 12/09/17 02:50, "Meghna Baijal" 
> > wrote:
> > > > >
> > > > > Hi All,
> > > > > We would like to initiate a change in the way the PR builds are
> > > > being triggered. At the moment, every time a Pull Request is
> created, a
> > > > build gets triggered on Jenkins. Additional builds also get triggered
> > due
> > > > to changes to the same PR.
> > > > > Too many PR builds leads to resource starvation and very long
> > > queues
> > > > and long build times. Hence we would like to add some checks where a
> > > human
> > > > reviewer manually marks it to something like “ok to build” before a
> PR
> > > > build is triggered.
> > > > >
> > > > > Do you think this approach would be helpful and we should move
> > > > forward with it?
> > > > >
> > > > > Thanks,
> > > > > Meghna Baijal
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Amazon Development Center Germany GmbH
> > > > > Berlin - Dresden - Aachen
> > > > > main office: Krausenstr. 38, 10117 Berlin
> > > > > Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
> > > > > Ust-ID: DE289237879
> > > > > Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
> > > >
> > >
> >
>

Re: MXNet: Run PR builds on Apache Jenkins only after the commit is reviewed

[Chris Olivier]

The majority of these iterations is to trigger a build on the broken CI in
hopes it will finally pass...

On Tue, Sep 12, 2017 at 11:15 AM Madan Jampani 
wrote:

> +1
> I second only running sanity test (lint) until manual approval.
>
> On Tue, Sep 12, 2017 at 11:05 AM, Naveen Swamy  wrote:
>
> > Just to be clear, the proposal is not to remove the PR build. It's only
> to
> > delay the PR build until a reviewer has looked at it and marks it
> Approved
> > or adds a Label to build. Once it's approved and PR build succeeds a
> > reviewer/committer can see the build result and merge to the master.
> >
> > I don't mean to pick on the author of this PR(Chris), I am just using
> this
> > build to support my argument.
> > https://builds.apache.org/view/Incubator%20Projects/job/
> > incubator-mxnet/view/change-requests/job/PR-7577/
> >  This has gone through 74 iterations, I understand not all of them are
> due
> > to changes and some of them are due to build instability and some dummy
> > commits to getting the PR build to pass. However, the PR has been under
> > review and changes being made for the last several days. I don't think it
> > warrants a build trigger for every new change. Each build on average
> takes
> > about 2 hours running on all platforms.
> >
> > Probably we can run a lean down version of the current PR build where we
> > have sanity-test(lint)->build on linux(cpu)->unit test on linux(cpu) ?
> >
> >
> > Thanks, Naveen
> >
> >
> >
> >
> > On Tue, Sep 12, 2017 at 4:27 AM, Joern Kottmann 
> > wrote:
> >
> > > Not sure how it works with jenkins, but other CI serves can look at
> > > the commit message and skip the CI run based on certain commands in
> > > it.
> > >
> > > Might make sense for small changes such as documentation updates, half
> > > done PRs, etc.
> > >
> > > Jörn
> > >
> > > On Tue, Sep 12, 2017 at 11:17 AM, Larroy, Pedro 
> > > wrote:
> > > > Hi
> > > >
> > > > I would like to integrate our CI system for devices to make sure PRs
> > > build on ARM / android etc. Who has admin rights on the repository so
> we
> > > can install the necessary hooks to trigger our builds?
> > > >
> > > >
> > > > Kind regards.
> > > > --
> > > >
> > > > Pedro
> > > >
> > > > On 12/09/17 02:50, "Meghna Baijal" 
> wrote:
> > > >
> > > > Hi All,
> > > > We would like to initiate a change in the way the PR builds are
> > > being triggered. At the moment, every time a Pull Request is created, a
> > > build gets triggered on Jenkins. Additional builds also get triggered
> due
> > > to changes to the same PR.
> > > > Too many PR builds leads to resource starvation and very long
> > queues
> > > and long build times. Hence we would like to add some checks where a
> > human
> > > reviewer manually marks it to something like “ok to build” before a PR
> > > build is triggered.
> > > >
> > > > Do you think this approach would be helpful and we should move
> > > forward with it?
> > > >
> > > > Thanks,
> > > > Meghna Baijal
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Amazon Development Center Germany GmbH
> > > > Berlin - Dresden - Aachen
> > > > main office: Krausenstr. 38, 10117 Berlin
> > > > Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
> > > > Ust-ID: DE289237879
> > > > Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
> > >
> >
>

Re: Jira and/or feature collision

[Naveen Swamy]

+1 for using Apache JIRA to track MXNet projects.

On Mon, Sep 11, 2017 at 11:01 AM, Chris Olivier 
wrote:

> Are there any objections to using the Apache JIRA for mxnet development
> tracking?  If not, how do we get it set up?
>
> On Mon, Sep 11, 2017 at 8:32 AM, Suneel Marthi  wrote:
>
> > I am not following, wouldn't a jira be assigned to the guy working on it
> -
> > so where is the question of multiple folks working on one feature
> >
> > On Mon, Sep 11, 2017 at 5:30 PM, Bhavin Thaker 
> > wrote:
> >
> > > +1 : Chris has an important question.
> > >
> > > How do we ensure that a feature/task for a particular Apache project is
> > not
> > > worked on by multiple folks at the same time?
> > >
> > > Is there a recommendation for a tool/process from the Apache group?
> > >
> > > This also provides a central, consolidated place to know who is working
> > on
> > > what.
> > >
> > > Bhavin Thaker.
> > >
> > > On Mon, Sep 11, 2017 at 5:06 AM Joern Kottmann 
> > wrote:
> > >
> > > > A good way to coordinate is to use the dev list and/or state on the
> > > > issues that you are interested in it and are working on it.
> > > >
> > > > We use Jira for years at Apache OpenNLP for all the issues we deal
> > > > with. At GitHub we use the Pull Request feature and synchronize all
> > > > comments with the corresponding Jira issue.
> > > >
> > > > My opinion is that Jira does much more then we actually use/need, and
> > > > is sometimes slightly unresponsive (e.g. takes 1 or 2 seconds to load
> > > > a new page) on the other hand, the GitHub issue tracker ist too
> simple
> > > > and is missing a few useful features.
> > > >
> > > > Jörn
> > > >
> > > > On Mon, Sep 11, 2017 at 10:18 AM, Henri Yandell 
> > > wrote:
> > > > > Yes, Apache JIRA is free to use.
> > > > >
> > > > > My observations of GitHub are that roadmaps/wishlist features need
> > > better
> > > > > separation from bug reports. Ideally you want a nice big list of
> > ideas
> > > > for
> > > > > future work, and a list of bug reports and smaller contributions
> that
> > > > > you're always driving down to zero. One way to do that could be to
> > put
> > > > the
> > > > > new features in JIRA, while keeping GitHub for bug reports, not
> sure
> > if
> > > > > that's what you were getting to Chris with the question.
> > > > >
> > > > > Hen
> > > > >
> > > > >
> > > > > On Sun, Sep 10, 2017 at 9:23 PM, sandeep krishnamurthy <
> > > > > sandeep.krishn...@gmail.com> wrote:
> > > > >
> > > > >> +1
> > > > >> Thanks Chris for bringing up this important topic.
> > > > >>
> > > > >> I would really like to prioritize this topic and request users and
> > > > mentors
> > > > >> to come up a process or suggestions on how to:
> > > > >> 1. Request for contributions from the community.
> > > > >> 2. A community member raising feature requests.
> > > > >> 3. A community member ready to contribute a feature or bug fix.
> > > > >> 4. A community member actively proposing and driving a big new
> > feature
> > > > for
> > > > >> the project.
> > > > >>
> > > > >> Projects in Github, Tagging Github issues with Call for
> > Contributions
> > > > may
> > > > >> seem very straight forward approach. But, is there any other
> > > > suggestions or
> > > > >> standard practice to drive such efforts?
> > > > >>
> > > > >> This will go a long way in keeping community members informed
> about
> > > what
> > > > >> next in the project, how can they be part and how they can set
> > future
> > > > >> directions in the project. Also, saving the time and effort in
> > > > duplication
> > > > >> of efforts.
> > > > >>
> > > > >> Regards,
> > > > >> Sandeep
> > > > >>
> > > > >> On Sat, Sep 9, 2017 at 4:48 AM, Chris Olivier <
> > cjolivie...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >> > Is Apache JIRA free to use? What do most projects use? While
> it's
> > > > natural
> > > > >> > that some companies have internal priorities which drive their
> > > > >> development
> > > > >> > plans, how do other Apache projects avoid having the same
> feature
> > > > >> developed
> > > > >> > independently by more than one party, because they isn't know
> the
> > > > other
> > > > >> was
> > > > >> > working on it already?  Or coordinate forces (so to speak) on a
> > > large
> > > > >> > feature or initiative?
> > > > >> >
> > > > >> > -Chris
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Sandeep Krishnamurthy
> > > > >>
> > > >
> > >
> >
>

Re: MXNet: Run PR builds on Apache Jenkins only after the commit is reviewed

[Madan Jampani]

+1
I second only running sanity test (lint) until manual approval.

On Tue, Sep 12, 2017 at 11:05 AM, Naveen Swamy  wrote:

> Just to be clear, the proposal is not to remove the PR build. It's only to
> delay the PR build until a reviewer has looked at it and marks it Approved
> or adds a Label to build. Once it's approved and PR build succeeds a
> reviewer/committer can see the build result and merge to the master.
>
> I don't mean to pick on the author of this PR(Chris), I am just using this
> build to support my argument.
> https://builds.apache.org/view/Incubator%20Projects/job/
> incubator-mxnet/view/change-requests/job/PR-7577/
>  This has gone through 74 iterations, I understand not all of them are due
> to changes and some of them are due to build instability and some dummy
> commits to getting the PR build to pass. However, the PR has been under
> review and changes being made for the last several days. I don't think it
> warrants a build trigger for every new change. Each build on average takes
> about 2 hours running on all platforms.
>
> Probably we can run a lean down version of the current PR build where we
> have sanity-test(lint)->build on linux(cpu)->unit test on linux(cpu) ?
>
>
> Thanks, Naveen
>
>
>
>
> On Tue, Sep 12, 2017 at 4:27 AM, Joern Kottmann 
> wrote:
>
> > Not sure how it works with jenkins, but other CI serves can look at
> > the commit message and skip the CI run based on certain commands in
> > it.
> >
> > Might make sense for small changes such as documentation updates, half
> > done PRs, etc.
> >
> > Jörn
> >
> > On Tue, Sep 12, 2017 at 11:17 AM, Larroy, Pedro 
> > wrote:
> > > Hi
> > >
> > > I would like to integrate our CI system for devices to make sure PRs
> > build on ARM / android etc. Who has admin rights on the repository so we
> > can install the necessary hooks to trigger our builds?
> > >
> > >
> > > Kind regards.
> > > --
> > >
> > > Pedro
> > >
> > > On 12/09/17 02:50, "Meghna Baijal"  wrote:
> > >
> > > Hi All,
> > > We would like to initiate a change in the way the PR builds are
> > being triggered. At the moment, every time a Pull Request is created, a
> > build gets triggered on Jenkins. Additional builds also get triggered due
> > to changes to the same PR.
> > > Too many PR builds leads to resource starvation and very long
> queues
> > and long build times. Hence we would like to add some checks where a
> human
> > reviewer manually marks it to something like “ok to build” before a PR
> > build is triggered.
> > >
> > > Do you think this approach would be helpful and we should move
> > forward with it?
> > >
> > > Thanks,
> > > Meghna Baijal
> > >
> > >
> > >
> > >
> > >
> > >
> > > Amazon Development Center Germany GmbH
> > > Berlin - Dresden - Aachen
> > > main office: Krausenstr. 38, 10117 Berlin
> > > Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
> > > Ust-ID: DE289237879
> > > Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
> >
>

Re: MXNet: Run PR builds on Apache Jenkins only after the commit is reviewed

[Naveen Swamy]

Just to be clear, the proposal is not to remove the PR build. It's only to
delay the PR build until a reviewer has looked at it and marks it Approved
or adds a Label to build. Once it's approved and PR build succeeds a
reviewer/committer can see the build result and merge to the master.

I don't mean to pick on the author of this PR(Chris), I am just using this
build to support my argument.
https://builds.apache.org/view/Incubator%20Projects/job/incubator-mxnet/view/change-requests/job/PR-7577/
 This has gone through 74 iterations, I understand not all of them are due
to changes and some of them are due to build instability and some dummy
commits to getting the PR build to pass. However, the PR has been under
review and changes being made for the last several days. I don't think it
warrants a build trigger for every new change. Each build on average takes
about 2 hours running on all platforms.

Probably we can run a lean down version of the current PR build where we
have sanity-test(lint)->build on linux(cpu)->unit test on linux(cpu) ?


Thanks, Naveen




On Tue, Sep 12, 2017 at 4:27 AM, Joern Kottmann  wrote:

> Not sure how it works with jenkins, but other CI serves can look at
> the commit message and skip the CI run based on certain commands in
> it.
>
> Might make sense for small changes such as documentation updates, half
> done PRs, etc.
>
> Jörn
>
> On Tue, Sep 12, 2017 at 11:17 AM, Larroy, Pedro 
> wrote:
> > Hi
> >
> > I would like to integrate our CI system for devices to make sure PRs
> build on ARM / android etc. Who has admin rights on the repository so we
> can install the necessary hooks to trigger our builds?
> >
> >
> > Kind regards.
> > --
> >
> > Pedro
> >
> > On 12/09/17 02:50, "Meghna Baijal"  wrote:
> >
> > Hi All,
> > We would like to initiate a change in the way the PR builds are
> being triggered. At the moment, every time a Pull Request is created, a
> build gets triggered on Jenkins. Additional builds also get triggered due
> to changes to the same PR.
> > Too many PR builds leads to resource starvation and very long queues
> and long build times. Hence we would like to add some checks where a human
> reviewer manually marks it to something like “ok to build” before a PR
> build is triggered.
> >
> > Do you think this approach would be helpful and we should move
> forward with it?
> >
> > Thanks,
> > Meghna Baijal
> >
> >
> >
> >
> >
> >
> > Amazon Development Center Germany GmbH
> > Berlin - Dresden - Aachen
> > main office: Krausenstr. 38, 10117 Berlin
> > Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
> > Ust-ID: DE289237879
> > Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
>

please subscribe me to MXNet Slack channel

[Max Kaznady]

MXNet website redesign

[Seb Kiureghian]

Hello Apache MXNet dev@ community,

The pPMC would like to update the website. Amazon has offered to contribute
resources and I'm acting as a liaison to gather feedback from the
community. The new design is currently on the /master page:
https://mxnet.incubator.apache.org/versions/master/



We appreciate your support and look forward to sharing our progress with
you. Please don't be shy to share your feedback or any items on your wish
list. I've also opened a Github issue
.


Thanks,

Seb

Re: MXNet: Run PR builds on Apache Jenkins only after the commit is reviewed

[Joern Kottmann]

Not sure how it works with jenkins, but other CI serves can look at
the commit message and skip the CI run based on certain commands in
it.

Might make sense for small changes such as documentation updates, half
done PRs, etc.

Jörn

On Tue, Sep 12, 2017 at 11:17 AM, Larroy, Pedro  wrote:
> Hi
>
> I would like to integrate our CI system for devices to make sure PRs build on 
> ARM / android etc. Who has admin rights on the repository so we can install 
> the necessary hooks to trigger our builds?
>
>
> Kind regards.
> --
>
> Pedro
>
> On 12/09/17 02:50, "Meghna Baijal"  wrote:
>
> Hi All,
> We would like to initiate a change in the way the PR builds are being 
> triggered. At the moment, every time a Pull Request is created, a build gets 
> triggered on Jenkins. Additional builds also get triggered due to changes to 
> the same PR.
> Too many PR builds leads to resource starvation and very long queues and 
> long build times. Hence we would like to add some checks where a human 
> reviewer manually marks it to something like “ok to build” before a PR build 
> is triggered.
>
> Do you think this approach would be helpful and we should move forward 
> with it?
>
> Thanks,
> Meghna Baijal
>
>
>
>
>
>
> Amazon Development Center Germany GmbH
> Berlin - Dresden - Aachen
> main office: Krausenstr. 38, 10117 Berlin
> Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
> Ust-ID: DE289237879
> Eingetragen am Amtsgericht Charlottenburg HRB 149173 B