Apache MXNet (incubating) Python Docker Images

[Meghna Baijal]

Hi All,

I am currently in the process of updating the python docker images for
Apache MXNet such that they are built on top of the pip binaries.
Until now these were built to use python 2.7 but with an upcoming PR I am
also adding python 3.5 docker images. I would like to know the community’s
preference on whether I should keep the *Python 2.7 Docker image as the
default or should I move to Python 3.5 as the default version*?

[1] The new python2 dockerfiles and build script can be found here.
<https://github.com/apache/incubator-mxnet/tree/master/docker/docker-python>
[2] The PR for python3 images is in progress and is here.
<https://github.com/apache/incubator-mxnet/pull/12791>

Thanks,
Meghna Baijal

Re: Publish MXNet images to DockerHub

[Meghna Baijal]

Hi Anirudh,
Thanks for bringing this up.
The Python Images are being actively released for each MXNet version. Until
last release I was using the script Mu has pointed out but from 1.2.1 I
replaced these dockerfiles to use the pip binaries instead of building from
source.
Images for all other language bindings were being released only until MXNet
0.12.0 since they were not being maintained. I think there are a couple of
github issues open to track broken dockerfiles.

Kellen,

I can help you publish the docker images to dockerhub.


Thanks,

Meghna Baijal




On Tue, Jul 24, 2018 at 4:45 PM Anirudh Acharya 
wrote:

> Yes that would be good. Also I just noticed that in the Installation
> instructions page only python has docker image installation instruction
> here -
>
> http://mxnet.incubator.apache.org/install/index.html?platform=Linux=Python=CPU
> Similar instructions need to be there for other bindings too.
>
> On Tue, Jul 24, 2018 at 4:04 PM kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
>
> > I was actually interested in pushing a version of MXNet with TensorRT
> > enabled some time in the next few weeks just so that people can
> experiment
> > with the feature without worrying about installing the right protoc and
> > onnx versions.  If people here think it's a good idea I can open a PR
> with
> > a runtime-docker folder with the intent that this work could be a
> template
> > for others who want to contribute runtime Dockerfiles?  If a few
> > contributors do put together an Dockerfile with TensorRT enabled, would
> it
> > be possible to get that image pushed to the MXNet Dockerhub repo by a
> > committer?
> >
> > On Sun, Jul 22, 2018 at 3:57 PM Anirudh Acharya 
> > wrote:
> >
> > > @Naveen No, I meant in general, for all bindings. Irrespective of
> whether
> > > we use a package management repository, being able to pull an image
> from
> > > docker hub would be convenient for anyone wanting to get started on
> MXNet
> > > or run services( as Kellen said).
> > >
> > >
> > > On Sun, Jul 22, 2018 at 11:20 AM kellen sunderland <
> > > kellen.sunderl...@gmail.com> wrote:
> > >
> > > > I think it's a good idea Anirudh.  It should help users easily get
> > MXNet
> > > up
> > > > and running whether they're running services, following tutorials,
> etc.
> > > >
> > > > On Sun, Jul 22, 2018 at 8:10 AM Naveen Swamy 
> > wrote:
> > > >
> > > > > I don't think we need for JVM languages, they have a good
> dependency
> > > > > management through Maven Central. We weren't publishing regularly
> to
> > > > Maven,
> > > > > now we do.
> > > > >
> > > > > Anirudh, I am guessing you are interested docker for R language, If
> > > the R
> > > > > packages were published to CRAN do you still see a need for docker
> ?
> > > > Could
> > > > > you elaborate how this would be helpful and easy if they were to
> use
> > > > other
> > > > > packages in CRAN?
> > > > >
> > > > > On Sat, Jul 21, 2018 at 10:51 PM, Anirudh Acharya <
> > > anirudhk...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Yes, correct cu90 is indeed there, thanks for pointing it.
> > > > > >
> > > > > > So the question, should we be publishing to Docker Hub as part of
> > the
> > > > > > release process so that bindings other than python are also
> > published
> > > > and
> > > > > > there is a policy on what cuda versions we publish?
> > > > > >
> > > > > >
> > > > > > Thanks
> > > > > > ANirudh
> > > > > >
> > > > > > On Sat, Jul 21, 2018 at 9:56 PM Mu Li 
> wrote:
> > > > > >
> > > > > > > cu90 and cu90mkl are also available, see
> > > > > > > https://hub.docker.com/r/mxnet/python/tags/
> > > > > > >
> > > > > > > On Sat, Jul 21, 2018 at 9:51 PM, Anirudh Acharya <
> > > > > anirudhk...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > The python binding that is actively maintained is
> > > > > > > >
> > > > > > > > mxnet-mkl  1.2.1
> > > > > > > >
> >

Re: Nightly tests README accurate?

[Meghna Baijal]

Hi,
This readme is incorrect and I am fixing this as a part of the nightly
tests PR soon.

Thanks,
Meghna

On Sun, Jun 17, 2018 at 7:05 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> I'm not a commiter, but I would say this is clearly not correct.  I would
> propose removing the doc until someone has time to verify that the steps
> work correctly, and that the descriptions are accurate.
>
> On Thu, Jun 14, 2018 at 10:04 PM Indhu  wrote:
>
> > Is the README
> > 
> for
> > the nightly tests accurate? For example,
> >
> > 1. Are tests being run on machines with Intel i7-4790 and 4 Nvidia GTX
> 970
> > Tis?
> > 2. Is http://ci.dmlc.ml/ the right place to look for build status?
> > 3. Is the instruction to run on Jenkins correct?
> >
> > If not, what all needs to be changed in that page?
> >
>

Re: [VOTE] Release Apache MXNet (incubating) version 1.2.0.RC0

[Meghna Baijal]

+1 (non-binding)


I Checked the following:

1. Signatures are ok

2. Source compiles

3. mnist test passes


Regards,

Meghna

On Thu, Apr 19, 2018 at 10:12 AM, Anirudh  wrote:

> Hi all,
>
> Given the weekend, I am extending the vote deadline to Sunday evening,
> April 22nd 7:40 PM PDT, considering Saturday and Sunday as half days(as
> done before).
>
> Anirudh
>
> On Wed, Apr 18, 2018 at 7:40 PM, Anirudh  wrote:
>
> > Hi everyone,
> >
> > This is a vote to release Apache MXNet (incubating) version 1.2.0. Voting
> > will start now (Wednesday, April 18th) and end at 7:40 PM PDT, Saturday,
> > April 21st.
> >
> > Link to the release notes:
> >
> > https://cwiki.apache.org/confluence/display/MXNET/
> > Apache+MXNet+%28incubating%29+1.2.0+Release+Notes
> >
> > Link to the release candidate 1.2.0.rc0:
> > https://github.com/apache/incubator-mxnet/releases/tag/1.2.0.rc0
> >
> > View this page, click on “Build from Source”, and use the source code
> > obtained from the 1.2.0.rc0 tag:
> > https://mxnet.incubator.apache.org/install/index.html
> >
> > (Note: The README.md points to the 1.2.0 tag and does not work at the
> > moment.)
> >
> > Please remember to TEST first before voting accordingly:
> > +1 = approve
> > +0 = no opinion
> > -1 = disapprove (provide reason)
> >
> > Thanks,
> >
> > Anirudh
> >
>

Re: Quick question about a submodule file’s license

[Meghna Baijal]

Hi All,
Until we resolve the licensing issue regarding this file [1] after
discussion on legal-discuss, there are a couple of ways to handle this file
for the 1.2 release as follows -

Option 1. Remove this one file [1] from the release src tar (though not
from the Github mxnet repo). This might lead to a couple of broken links in
the Googletest submodule.
Option 2. Let this file [1] remain in the src tar and add this open
licensing issue to known issues in the release notes.

Please let me know if you have any suggestions or opinions on this.

[1]
https://github.com/google/googletest/blob/ec44c6c1675c25b9827aacd08c02433cccde7780/googlemock/docs/DevGuide.md

Thanks,
Meghna Baijal



On Fri, Apr 6, 2018 at 11:43 AM, Meghna Baijal <meghnabaijal2...@gmail.com>
wrote:

> Thank you Henri, Pedro.
> Yes, we are only referring to the one documentation file within google
> test.
>
> Henri,
> Could you please guide me on the best approach to take an issue to the
> legal-discuss@.
>
> Thanks,
> Meghna Baijal
>
> On Fri, Apr 6, 2018 at 7:42 AM, Pedro Larroy <pedro.larroy.li...@gmail.com
> > wrote:
>
>> Good point, I thought text is media, but I'm not a lawyer. Just to be
>> clear, that this refers to that particular documentation file, the
>> software
>> is BSD licensed.
>>
>> Pedro.
>>
>> On Fri, Apr 6, 2018 at 9:41 AM, Hen <bay...@apache.org> wrote:
>>
>> > Noting that the linked FAQ is for CC-BY-SA and unmodified media (ie:
>> > images, sound, video); so it's not relevant.
>> >
>> > I think this is worth raising on legal-discuss@. CC-BY software is an
>> > issue, but resolved.html hasn't stated anything regarding CC-BY for a
>> > documentation file.
>> >
>> > Hen
>> >
>> > On Thu, Apr 5, 2018 at 10:43 AM, Meghna Baijal <
>> meghnabaijal2...@gmail.com
>> > >
>> > wrote:
>> >
>> > > Thank you Pedro for looking into this. The suggestion came from PMC
>> > during
>> > > 1.1 voting cycle.
>> > > However, the link does seem to indicate that including it should be
>> ok. I
>> > > also found other Apache projects that have included this file.
>> > >
>> > > I will review the LICENSE and NOTICE requirements and let the file
>> remain
>> > > in the source.
>> > >
>> > > Thanks Again!
>> > >
>> > > On Thu, Apr 5, 2018 at 9:22 AM, Pedro Larroy <
>> > pedro.larroy.li...@gmail.com
>> > > >
>> > > wrote:
>> > >
>> > > > Hi Meghna.
>> > > >
>> > > > Are you sure the DevGuide of googletest is a problem?
>> > > >
>> > > > Check this out:
>> > > >
>> > > > https://www.apache.org/legal/resolved.html#cc-sa
>> > > >
>> > > >
>> > > > Pedro.
>> > > >
>> > > >
>> > > > On Thu, Apr 5, 2018 at 2:59 AM, Meghna Baijal <
>> > > meghnabaijal2...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > Hello Everyone,
>> > > > > There was a suggestion during the 1.1 release vote to remove this
>> > file
>> > > > [1]
>> > > > > from the released source since it is licensed under CC-BY-2.5.
>> > > > >
>> > > > > However, this file is a part of the googletest submodule and can’t
>> > > simply
>> > > > > be removed. Does anyone know how we can deal with the licensing of
>> > this
>> > > > > file ?
>> > > > >
>> > > > > [1] *Path to file in mxnet -*
>> > > > > apache-mxnet-src-1.1.0.rc1-incubating/3rdparty/
>> > > > googletest/googlemock/docs/
>> > > > > DevGuide.md
>> > > > > [2] *Link to github issue* :
>> > > > > https://github.com/apache/incubator-mxnet/issues/10330
>> > > > >
>> > > > > Thanks,
>> > > > > Meghna
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: Quick question about a submodule file’s license

[Meghna Baijal]

Thank you Pedro for looking into this. The suggestion came from PMC during
1.1 voting cycle.
However, the link does seem to indicate that including it should be ok. I
also found other Apache projects that have included this file.

I will review the LICENSE and NOTICE requirements and let the file remain
in the source.

Thanks Again!

On Thu, Apr 5, 2018 at 9:22 AM, Pedro Larroy <pedro.larroy.li...@gmail.com>
wrote:

> Hi Meghna.
>
> Are you sure the DevGuide of googletest is a problem?
>
> Check this out:
>
> https://www.apache.org/legal/resolved.html#cc-sa
>
>
> Pedro.
>
>
> On Thu, Apr 5, 2018 at 2:59 AM, Meghna Baijal <meghnabaijal2...@gmail.com>
> wrote:
>
> > Hello Everyone,
> > There was a suggestion during the 1.1 release vote to remove this file
> [1]
> > from the released source since it is licensed under CC-BY-2.5.
> >
> > However, this file is a part of the googletest submodule and can’t simply
> > be removed. Does anyone know how we can deal with the licensing of this
> > file ?
> >
> > [1] *Path to file in mxnet -*
> > apache-mxnet-src-1.1.0.rc1-incubating/3rdparty/
> googletest/googlemock/docs/
> > DevGuide.md
> > [2] *Link to github issue* :
> > https://github.com/apache/incubator-mxnet/issues/10330
> >
> > Thanks,
> > Meghna
> >
>

Quick question about a submodule file’s license

[Meghna Baijal]

Hello Everyone,
There was a suggestion during the 1.1 release vote to remove this file [1]
from the released source since it is licensed under CC-BY-2.5.

However, this file is a part of the googletest submodule and can’t simply
be removed. Does anyone know how we can deal with the licensing of this
file ?

[1] *Path to file in mxnet -*
apache-mxnet-src-1.1.0.rc1-incubating/3rdparty/googletest/googlemock/docs/DevGuide.md
[2] *Link to github issue* :
https://github.com/apache/incubator-mxnet/issues/10330

Thanks,
Meghna

Re: Please Help Fix MXNet Licensing Issues for the next Release!

[Meghna Baijal]

Henri,
Thanks for the detailed information,
Based on your review and the comments on the general VOTE thread, I have
made some changes to the top level LICENSE file in this PR
<https://github.com/apache/incubator-mxnet/pull/9701>.

The final changes to the LICENSE file can be summarized as follows -

1. I have reverted commit 8930d96 (PR #9484)

2. Revisited some comments from previous release which are now relevant and
made appropriate changes - based on points 8-11 and 13 to 19 in this wiki,
section E
<https://cwiki.apache.org/confluence/display/MXNET/MXNet+Source+Licenses>

3. Ran a fresh search for dependencies with a separate license and added
the missing ones to the LICENSE file.

4. Reviewed the Apache Policy and confirmed to the best of my understanding
the LICENSE file complies with the guidelines.


Please let me know if there are any other major issues in this file or any
other issue that should be addressed. I want to be sure I fix these before
the next RC is created.


Thanks,

Meghna Baijal

On Thu, Feb 1, 2018 at 9:58 AM, Hen <bay...@apache.org> wrote:

> I think we should revert the license file to the previous, and improve from
> there. The policy is:
>
> "The LICENSE file MUST contain the full text of the Apache License 2.0
> <http://www.apache.org/licenses/LICENSE-2.0.txt>.
>
> When a package bundles code under several licenses, the LICENSE file MUST
> contain details of all these licenses. For each component which is not
> Apache licensed, details of the component MUST be appended to the LICENSE
> file.
> The component license itself MUST either be appended or else stored
> elsewhere in the package with a pointer to it from the LICENSE file, e.g.
> if the license is long."
>
> Looking at Justin's feedback linked on the wiki page, his objection was
> missing items in the license file.
>
> I know there was a suggestion to remove the listing of components to make
> it harder to have missing items, but that shouldn't mean removing license
> text. If two components don't have exactly the same license text then they
> are not the same license. Most commonly nowadays that means that you can't
> merge BSD licenses together, and sometimes can't merge MIT together
> (depending on variants and how you handle the copyright statements).
>
> Hen
>
> On Tue, Jan 30, 2018 at 2:42 PM, Meghna Baijal <meghnabaijal2...@gmail.com
> >
> wrote:
>
> > Hello Henri,
> >
> > Thank you for your review.
> > As I have detailed in this PR
> > <https://github.com/apache/incubator-mxnet/pull/9484>, the previous
> > version
> > of the LICENSE file contained a list of packages which were using the BSD
> > license (based on the license text), along with the whole content of the
> > actual license (Warp-CTC, Caffe, Cub, Sphinx etc). Since it was decided
> to
> > remove this list, to be safe, I left one copy of the BSD license text in
> > there. I agree this might not be the right way of doing it and would be
> > happy to fix it.
> >
> > However, there has been a lot of back and forth on this top level LICENSE
> > and NOTICE file and it would be great if you could help me understand the
> > Apache policy correctly and fix these appropriately.
> >
> > Thanks,
> > Meghna Baijal
> >
> >
> >
> >
> > On Mon, Jan 29, 2018 at 7:54 PM, Hen <bay...@apache.org> wrote:
> >
> > > The last paragraph of the LICENSE looks suspect. I doubt we've taken
> code
> > > from the BSD project. I would suggest deleting that last paragraph.
> > >
> > > With MIT and BSD licenses you do have to be careful that the text of
> each
> > > is the same. Each term is often used for a family of related licenses.
> > >
> > > Additionally each of MIT and BSD typically has a Copyright
> > > statement accompanying it. If the rules say to remove that from
> LICENSE,
> > > then we should be adding it to the NOTICE.
> > >
> > > Hen
> > >
> > >
> > > On Wed, Jan 24, 2018 at 5:07 PM, Meghna Baijal <
> > meghnabaijal2...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Marco,
> > > > Thanks a lot for looking through this ! Some comments below -
> > > >
> > > >1. *R-package:* Before we create the final tarball for the
> release,
> > > the
> > > >R-package is explicitly removed from the cloned MXNet repo. The
> only
> > > > info I
> > > >have in this regard is that “there are some unresolved licensing
> > > issues
> > > > in
> > > >this package and cannot be releas

Re: Release plan - MXNET 1.0.1

[Meghna Baijal]

I agree. If the release candidate is being cut from the master branch, it
should be considered a minor release.

Anyway the effort involved in the release process is exactly the same in
either case.

Thanks,
Meghna

On Jan 24, 2018 8:56 PM, "Marco de Abreu" 
wrote:

> Are there any particular reasons why we are classifying this release as
> patch instead of minor release? As far as I know, we don't have any tests
> in place to determine API changes and thus can't guarantee that this is an
> actual patch release. Considering the fact that PRs have been merged
> without having semantic versioning in place, this could be quite risky.
>
> Instead, I'd rather propose to make a minor release 1.1 instead of patch
> release 1.0.1.
>
> -Marco
>
> Am 24.01.2018 7:20 nachm. schrieb "Zha, Sheng" :
>
> > There’s an experimental API for text data indexing and embedding in
> > mx.contrib.text.
> >
> > - Sent by my thumb
> >
> > > On Jan 24, 2018, at 7:08 PM, Chris Olivier 
> > wrote:
> > >
> > > the profiling PR contains a small breaking change, but i don’t think
> it’s
> > > going into 1.0.1
> > >
> > >> On Wed, Jan 24, 2018 at 6:48 PM Haibin Lin 
> > wrote:
> > >>
> > >> Hi everyone,
> > >>
> > >> Since the plan was to cut a branch from the master branch, the code
> will
> > >> include changes other than the bug fix PRs noted in the release note.
> Is
> > >> anyone aware of any API changes in the current MXNet master branch? In
> > >> particular, are there backward incompatible ones?
> > >>
> > >> Best,
> > >> Haibin
> > >>
> > >> On Tue, Jan 23, 2018 at 11:25 AM, Haibin Lin <
> haibin.lin@gmail.com>
> > >> wrote:
> > >>
> > >>> Hi Sheng,
> > >>>
> > >>> 1. I've been following the discussion on the branching & versioning
> > >>> thread. Features like MKLDNN integration should not go to patch
> release
> > >>> 1.0.1, and it's risky to merge large PRs right before the release.
> I've
> > >>> removed the MKLDNN section from the release note.
> https://cwiki.apache
> > .
> > >>> org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+
> > >>> 1.0.1+Release+Notes
> > >>>
> > >>> 2. I agree that we should aim for better test coverage & stable CI,
> and
> > >>> get those disabled/flaky tests fixed eventually. Fixing these
> requires
> > >>> efforts from the community and I strongly encourage contributors to
> > help.
> > >>> Removing the corresponding feature from the release doesn't sound
> > >> practical
> > >>> since users might be already using some of those. I suggest that we
> > keep
> > >>> track of these tests on Apache Wiki and make sure they are addressed
> > for
> > >>> the release after 1.0.1.
> > >>>
> > >>> Hi everyone,
> > >>>
> > >>> In terms of the current status for this release, all critical bug
> fixes
> > >>> are merged (to the best of my knowledge) and we have made good
> progress
> > >>> fixing license issues. As Meghna mentioned, a list of open questions
> > >>> regarding license is at
> > >> https://cwiki.apache.org/confluence/display/MXNET/
> > >>> MXNet+Source+Licenses section D - it would be great if we can get
> more
> > >>> clarification/help/feedback from Apache mentors.
> > >>>
> > >>> I suggest that we shoot for code freeze for 1.0.1 rc0 this Wednesday.
> > >> Does
> > >>> anyone have concern or objection on this?
> > >>>
> > >>> Best,
> > >>> Haibin
> > >>>
> > >>> On Tue, Jan 23, 2018 at 7:51 AM, Steffen Rochel <
> > steffenroc...@gmail.com
> > >>>
> > >>> wrote:
> > >>>
> >  Hi Sheng -
> >  1. branch usage and versioning - lets converge our discussion and
> > >> document
> >  the agreement on wiki. I started a draft summarizing my
> understanding
> > of
> >  the proposal at
> >  https://cwiki.apache.org/confluence/display/MXNET/Release+
> >  Versioning+and+Branching.
> >  Lets work together to refine and clarify the draft, so we have
> clarity
> >  going forward. I'm inviting everyone to contribute to this
> discussion.
> >  As MKLDNN integration is not ready yet and we want to release all
> the
> > >> good
> >  improvements including updates in tutorials and documentation I
> > suggest
> > >> we
> >  move forward with the release asap. As we don't have major features
> or
> >  non-compatible API changes (to best of my knowledge) I think it is
> >  appropriate to label the release as 1.0.1.
> >  Note: This label indicates a patch release. Patch releases should be
> >  created from the related release branch. As we didn't plan for it
> and
> > to
> >  minimize overhead I suggest we make a one time exception to cut the
> > >> 1.0.1
> >  release from master branch and clearly communicate in release notes.
> > >> Going
> >  forward we should follow the methodology for versioning and
> branching
> > to
> >  whatever we agree on.
> >  2. Disabled tests: I agree with your concerns that we had to disable
> > 13
> 

Re: Please Help Fix MXNet Licensing Issues for the next Release!

[Meghna Baijal]

Marco,
Thanks a lot for looking through this ! Some comments below -

   1. *R-package:* Before we create the final tarball for the release, the
   R-package is explicitly removed from the cloned MXNet repo. The only info I
   have in this regard is that “there are some unresolved licensing issues in
   this package and cannot be released”.
   2. *Dockerfiles:* You can refer to this PR for details
   https://github.com/apache/incubator-mxnet/pull/9500. I plan to handle
   this differently next time.
   3. *perl-package*: There were some copyright issues in the past with
   this folder. I just excluded it to be on the safer side, but I think it
   should be ok to add the ASF header here.
   4. *docs/** - Yes, agreed. I will add the licenses where needed but I
   still think its safer to exclude the folder as a whole from the RAT check.
   5. *CODEOWNERS* - agreed, will add to the list of excluded files.
   6. *appveyor.yml:* Is this file relevant anymore? I will add a license
   anyway.
   7. *tests/ci_build/pylintrc:* ok
   8. *example/image-classification/predict-cpp/image-classification-predict.cc
   <http://classification-predict.cc/>* - yes, mutiple opinions on this one
   during the voting process too.
   9. *gradle-wrapper *- yes, I remember that one too. I am hoping for some
   suggestion on how this can be handled without breaking anything.

Best,
Meghna

On Wed, Jan 24, 2018 at 4:47 PM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:

> Hi Meghna,
>
> thank you for driving the licensing issues!
>
> - R-package: In the linked wiki, you're mentioning that R-package is not a
> part of the release. Could you please elaborate? From my understand, all
> files in the GitHub repository are part of the release.
> - Dockerfiles: I just checked another Apache-project [1] and it seems like
> they are successfully applying the license to dockerfiles. Do you see any
> issues in doing so?
> - perl-package: Same as R-package
> - docs/*: Just my personal opinion, but I agree that it might not be a good
> idea to have the license inside every file as some of them are directly
> getting sent out. But we have some shell-scripts inside this directory, so
> they'll need proper licensing.
> - CODEOWNERS: This is a setting file got our GitHub repository and not part
> of the release or the software itself. Thus I'd say that there's no need
> for a license - especially considering that the content itself has no
> value.
> - appveyor.yml: I'd treat this like the Jenkinsfile and apply a license.
> - tests/ci_build/pylintrc: I'd add a license
> - example/image-classification/predict-cpp/image-
> classification-predict.cc:
> It seems like Mu has had issues with the licensing of this file in the
> past. Maybe consult him
> - gradle-wrapper: I don't have a link, but I'm very sure that there was a
> discussion regarding this jar-file during the last release.
>
> Anybody, please feel free to correct me if I made a wrong assumption.
>
> Best regards,
> Marco
>
> [1]: https://github.com/apache/bookkeeper/blob/master/docker/Dockerfile
>
> On Wed, Jan 24, 2018 at 4:27 PM, Meghna Baijal <meghnabaijal2...@gmail.com
> >
> wrote:
>
> > Hello,
> >
> > This is an update on the current status of the license fixes (all details
> > in the wiki linked below)–
> >
> >1. I am constantly updating this wiki, so you can check it at any time
> >to know the status -
> >https://cwiki.apache.org/confluence/display/MXNET/
> MXNet+Source+Licenses
> >2. All 7 PRs have been merged however if anyone has any comments on
> >these changes please let me know.
> >3. There are still 6-7 files that do not have a license and are
> failing
> >the RAT check. These are files I was not entirely confident about
> > adding an
> >apache header to.
> >4. There is a list of file formats, files and directories that have
> >currently been excluded from the RAT check. I have mentioned the exact
> >reason for adding these to this list in the wiki. However, this list
> > needs
> >to be reviewed and validated.
> >
> >
> > *Coming Up Later –*
> >
> > *1. *Once points 3 and 4 above have been fixed, I will set up a RAT job
> in
> > CI which will run a nightly check (This is currently being run in a local
> > Jenkins setup)
> >
> > 2. I will also add a rat-excludes file to the mxnet repo so that anyone
> can
> > run a RAT check locally to check the licenses.
> >
> >
> > I am still looking for the MXNet community and the Mentors to review the
> > open questions in the wiki and help me resolve these before the upcoming
> > release!
> >
> >
> > Thank you,
> >

Re: Please Help Fix MXNet Licensing Issues for the next Release!

[Meghna Baijal]

Hello,

This is an update on the current status of the license fixes (all details
in the wiki linked below)–

   1. I am constantly updating this wiki, so you can check it at any time
   to know the status -
   https://cwiki.apache.org/confluence/display/MXNET/MXNet+Source+Licenses
   2. All 7 PRs have been merged however if anyone has any comments on
   these changes please let me know.
   3. There are still 6-7 files that do not have a license and are failing
   the RAT check. These are files I was not entirely confident about adding an
   apache header to.
   4. There is a list of file formats, files and directories that have
   currently been excluded from the RAT check. I have mentioned the exact
   reason for adding these to this list in the wiki. However, this list needs
   to be reviewed and validated.


*Coming Up Later –*

*1. *Once points 3 and 4 above have been fixed, I will set up a RAT job in
CI which will run a nightly check (This is currently being run in a local
Jenkins setup)

2. I will also add a rat-excludes file to the mxnet repo so that anyone can
run a RAT check locally to check the licenses.


I am still looking for the MXNet community and the Mentors to review the
open questions in the wiki and help me resolve these before the upcoming
release!


Thank you,

Meghna Baijal



On Thu, Jan 18, 2018 at 9:14 PM, Meghna Baijal <meghnabaijal2...@gmail.com>
wrote:

> Hello All!
>
> I am currently attempting to fix the licensing issues in MXNet. These are
> being tracked in this wiki -
>
> *https://cwiki.apache.org/confluence/display/MXNET/MXNet+Source+Licenses
> <https://cwiki.apache.org/confluence/display/MXNET/MXNet+Source+Licenses>*
>
> You can follow the links in this wiki to find the following details -
> 1. Links to relevant email threads which point the license issues out.
> 2. Links to Github Issues created based on these emails.
> 3. Apache pages which details the licensing policies.
> 4. *The PRs created to fix these issues.* (These need review and all help
> is welcome!)
> 5. A table to track the high level issues and their progress.
> 6. And a list of open *issues/questions/doubts/concerns* that need some
> answers.
>
> I would appreciate any comments/ feedback/ suggestions from the community
> regarding this work and it would be particularly helpful if you could
> help review and validate the PRs and other planned changes.
>
> This is still a work in progress and there are a few files/folders that
> are currently excluded from the Apache RAT checks. Also, there are around
> 30 files that are still failing Apache RAT check (both lists are in the
> wiki). If you know how to fix any of these remaining issues, please let me
> know or even better create a PR!
>
> Do let me know if I can provide more details on any of the points.
>
> Thanks,
> Meghna Baijal
>

Please Help Fix MXNet Licensing Issues for the next Release!

[Meghna Baijal]

Hello All!

I am currently attempting to fix the licensing issues in MXNet. These are
being tracked in this wiki -

*https://cwiki.apache.org/confluence/display/MXNET/MXNet+Source+Licenses
<https://cwiki.apache.org/confluence/display/MXNET/MXNet+Source+Licenses>*

You can follow the links in this wiki to find the following details -
1. Links to relevant email threads which point the license issues out.
2. Links to Github Issues created based on these emails.
3. Apache pages which details the licensing policies.
4. *The PRs created to fix these issues.* (These need review and all help
is welcome!)
5. A table to track the high level issues and their progress.
6. And a list of open *issues/questions/doubts/concerns* that need some
answers.

I would appreciate any comments/ feedback/ suggestions from the community
regarding this work and it would be particularly helpful if you could help
review and validate the PRs and other planned changes.

This is still a work in progress and there are a few files/folders that are
currently excluded from the Apache RAT checks. Also, there are around 30
files that are still failing Apache RAT check (both lists are in the wiki).
If you know how to fix any of these remaining issues, please let me know or
even better create a PR!

Do let me know if I can provide more details on any of the points.

Thanks,
Meghna Baijal

Re: [VOTE] Apache MXNet (incubating) 1.0.0 release RC0

[Meghna Baijal]

Hello Justin, Henri,
Thank you for your input.

Justin,
Chris ran Apache Rat on MXNet this morning. Several issues found here, in
addition to your comments that needed a fix have been addressed in the
following 2 PRS -
1. https://github.com/apache/incubator-mxnet/pull/8873/
2. https://github.com/apache/incubator-mxnet/pull/8876/

It would be helpful if you could review these changes.

Thanks,
Meghna Baijal



On Wed, Nov 29, 2017 at 3:18 PM, Justin Mclean <justinmcl...@me.com> wrote:

> Hi,
>
> >> - A number of source file are missing license headers e.g. [15][16] [18]
> >> [19] and many others
> >>
> >
> > Many of these are not Apache MXNet files but from dependencies. I'll
> > suggest on dev@ that these submodules be moved into a third-party/
> > directory.
>
> Having that clearly identified would certainly make the release a lot
> easier to review.
>
> > Why would it be? We only have to include the LICENSE from TVM, we don't
> > need to name them.
>
> In general all bundled software need to be added. [1]
>
> > If TVM want to be identified, they should add a NOTICE file.
>
> Licenses of permissively bundled software go in LICENSE with a few
> exceptions. [2] Apache licensed (v2) doesn't have to me listed [3] but is
> useful to list and you're listing other Apache licensed software in LICENSE
> so it seemed odd to omit it.
>
> Again I suggest you run rat over the release and see if you can fix up
> what it finds. An annotated rat exclusion file would also be a lot of help.
> Just try not to make the exclusions too wide as you may miss something.
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/licensing-howto.html#guiding-principle
> 2. http://www.apache.org/dev/licensing-howto.html#permissive-deps
> 3. http://www.apache.org/dev/licensing-howto.html#alv2-dep

Re: [Important] Please Help make the Apache MXNet (incubating) 1.0 Release Notes Better!

[Meghna Baijal]

Apologies. Done.

On Mon, Nov 20, 2017 at 2:18 PM, Chris Olivier <cjolivie...@gmail.com>
wrote:

> No write access :(
>
> On Mon, Nov 20, 2017 at 2:16 PM, Meghna Baijal <meghnabaijal2...@gmail.com
> >
> wrote:
>
> > Hello All,
> > As you know I am currently working on finalizing the Release Candidate
> for
> > Apache MXNet (incubating) 1.0 Release. Anyone who has contributed to this
> > release, could you please go through the release notes in the shared doc
> > linked below and review/make changes as needed.
> >
> > Link -
> > https://docs.google.com/document/d/1SdFwiTXlFBMmyVfEHpe7s3jteWxqf
> > UzsxTgbagcZWzo/edit?usp=sharing
> >
> > The notes are very limited in details so feel free to add any
> details/links
> > to tutorials or documentation that you think will be useful. Changes can
> be
> > made until *EOD tonight (Monday, 11/20)* after which they need to be
> merged
> > into the NEWS.md.
> >
> > Thanks,
> > Meghna Baijal
> >
>

Re: Protected master needs to be turned off

[Meghna Baijal]

-1 (non binding)
While I agree that the protected master is slowing development but it is
also helping identify problematic tests. If we don't do this now, the same
issues will exist on the new CI.

On Sun, Nov 19, 2017 at 1:51 PM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:

> Hello,
>
> -1 (non binding)
>
> Who is going to be responsible for changes breaking tests and having other
> side effects after they have been merged? I'm afraid that this will harm
> further development. At the moment I'm the responsible person for setting
> up the new CI and so far have my results shown that not the CI itself is
> the problem but also the stability of our code as well as the tests
> themselves. At the moment we are having big issues to get a stable CI
> because MXNet seems to be relying on so specific architectures,
> dependencies and other factors which I'm not even able to track down that
> this causes everything to be unstable.
>
> Just to point it out: If we encounter so many problems while setting up a
> CI system, doesn't that mean that our users and customers are also going to
> face those issues as soon as things are getting more complicated? This is a
> red flag in my opinion and I'm really looking forward to the usability
> Sprint, but at the moment I'm afraid that an unprotected master will make
> the situation even worse. It's already enough work to isolate and fix the
> current issues, but if new untested changes get merged, this is going to be
> like fighting a wildfire with a bottle of water.
>
> So please revise your thoughts. If anybody is blocked by the protected
> master, I would really appreciate it if they could approach me personally
> in order to help stabilising the current situation. Just feeding in more
> and more changes on one end while we're fixing issues on the other end
> won't get us anywhere.
>
> Best regards,
> Marco
>
> Am 19.11.2017 10:08 nachm. schrieb "Chris Olivier"  >:
>
> > Revised:
> >
> >
> > +1 at least until new CI is implemented. Then reevaluate.
> >
> > On Sun, Nov 19, 2017 at 1:07 PM Chris Olivier 
> > wrote:
> >
> > > +1
> > >
> > >
> > > On Sun, Nov 19, 2017 at 12:52 PM Zha, Sheng 
> wrote:
> > >
> > >> +1
> > >>
> > >> Best regards,
> > >> -sz
> > >>
> > >> On 11/19/17, 12:51 PM, "Eric Xie"  wrote:
> > >>
> > >> Hi all,
> > >> I'm starting this thread to vote on turning off protected master.
> > The
> > >> reasons are:
> > >>
> > >> 1. Since we turned on protected master pending PRs has grown from
> 40
> > >> to 80. It is severely slowing down development.
> > >>
> > >> 2. Committers, not CI, are ultimately responsible for the code
> they
> > >> merge. You should only override the CI when you are very confident
> that
> > CI
> > >> is the problem, not your code. If it turns out you are wrong, you
> should
> > >> fix it ASAP. This is the bare minimum requirement for all committers:
> BE
> > >> RESPONSIBLE.
> > >>
> > >> I'm aware of the argument for using protected master: It make sure
> > >> that master is stable.
> > >>
> > >> Well, master will be most stable if we stop adding any commits to
> > it.
> > >> But that's not what we want is it?
> > >>
> > >> Protected master hardly adds any stability. The faulty tests that
> > >> breaks master at random got merged into master because they happened
> to
> > >> succeed once.
> > >>
> > >> Thanks,
> > >> Junyuan Xie
> > >>
> > >>
> > >>
> > >>
> >
>

Re: Release plan - Apache MXNet (incubating) 1.0

[Meghna Baijal]

Hi All,
Since many PRs are still in progress or in the build queue, the code freeze
has been extended until *Sunday, November 26th.*
It would be very helpful if you could respond to this email with any PRs
that are still pending to be merged into master and must be included in the
1.0 release.

Thanks,
Meghna Baijal

On Mon, Nov 13, 2017 at 11:24 PM, Meghna Baijal <meghnabaijal2...@gmail.com>
wrote:

> I am starting the process to prepare for Apache MXNet (incubating) 1.0
> Release. I have drafted the release notes
> <https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.0+Release+Notes>to
> cover the tasks planned this release.
>
> A release candidate will be cut next week around Tuesday, November 21th
> and voting will commence from then until Friday, November 24th. If you have
> any additional features in progress and would like to include it in this
> release, please make sure they have been merged by Thursday, November 16,
> 2017 and comment so I may update the release notes.
>
>
> Feel free to add any other comments/suggestions.
>
> Thanks,
>
> Meghna Baijal
>

Release plan - Apache MXNet (incubating) 1.0

[Meghna Baijal]

I am starting the process to prepare for Apache MXNet (incubating) 1.0
Release. I have drafted the release notes
<https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.0+Release+Notes>to
cover the tasks planned this release.

A release candidate will be cut next week around Tuesday, November 21th and
voting will commence from then until Friday, November 24th. If you have any
additional features in progress and would like to include it in this
release, please make sure they have been merged by Thursday, November 16,
2017 and comment so I may update the release notes.


Feel free to add any other comments/suggestions.

Thanks,

Meghna Baijal

[RESULT][VOTE] Release Apache MXNet (incubating) Version 0.12.1.rc0

[Meghna Baijal]

Hi All,

The vote for releasing Apache MXNet (incubating) 0.12.1 RC0 passed with the
following result -


+1 binding

- Chris Olivier

- Sebastian

- Indhu Bharathi


There was no -1 and 0


Vote thread
https://lists.apache.org/thread.html/254d533bf9b2df9ac2de960ba6303d89d5d39a783573b4c6e47e4e08@%3Cdev.mxnet.apache.org%3E


I am now going to create a vote on the general@ list.


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
<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

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 <meghnabaijal2...@gmail.com>
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 <pllar...@amazon.de> 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" <meghnabaijal2...@gmail.com> 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 <cjolivie...@gmail.com>
>> 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
>> > > <meghnabaijal2...@gmail.com> 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] 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 <pllar...@amazon.de> 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" <meghnabaijal2...@gmail.com> 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 <cjolivie...@gmail.com>
> 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
> > > <meghnabaijal2...@gmail.com> 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). Th

Re: [Proposal] Stabilizing Apache MXNet CI build system

[Meghna Baijal]

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 <cjolivie...@gmail.com> 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
> > <meghnabaijal2...@gmail.com> 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 <bay...@apache.org> 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
> > >> > > systems:
> > &

[VOTE] Release Apache MXNet(incubating) version 0.12.1.rc0

[Meghna Baijal]

This is the vote to release Apache MXNet (incubating) version 0.12.1.

Voting will start now (Tuesday, November 7, 2017) and

close Friday, November 10, 2017


Link to release notes:

https://cwiki.apache.org/confluence/display/MXNET/MXNet+0.12.1+Release+Notes


Link to release candidate 0.12.1.rc0:

https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.12.1.rc0/


View this page and scroll down to “Build from Source” to build this project:

https://mxnet.incubator.apache.org/install/index.html


The release tag can be found here:

https://github.com/apache/incubator-mxnet/tree/0.12.1.rc0

(Note: The README.md points to the 0.12.1 tag and does not work at the
moment.)



Please make sure you TEST before you vote accordingly:


+1 = approve


+0 = no opinion


-1 = disapprove (provide reason)



Thanks,

Meghna Baijal

The process for a patch release

[Meghna Baijal]

Hi All,
A patch release is being planned for Apache MXNet(incubating) to include
some important bug fixes.
I want to confirm that for a patch release, there is no RC and voting step.

Effectively the process looks something like this -

Step 1: Cherrypick all the necessary bugfixes into the existing release
branch.

Step 2: Add a PR to update the version number etc (Example
https://github.com/apache/incubator-mxnet/commit/e0c7906693f0c79b0ce34a4d777c26a6bf1903c1
)

Step 3: Make sure the release branch build passes on builds.apache.jenkins
and nightly tests

Step 4: tag the release branch in GitHub with the release tag - example
0.12.1

Step 5: Download from the repo and checkout the tag, package it and Sign
the src code into 'apache-mxnet-src-0.12.1-incubating'

Step 6: Validate the signatures and test

Step 7: Update the website. (pip and docker release)

Step 8: Upload the src tar to the final destination -
http://www.apache.org/dist/incubator/mxnet/

Step 9: Announce the patch release

Thanks,
Meghna Baijal

Re: [Proposal] Stabilizing Apache MXNet CI build system

[Meghna Baijal]

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 <bay...@apache.org> 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
> > > systems:
> > > >
> > > >1. Apache Jenkins master is overloaded and we see issues like -
> > unable
> > > >to trigger builds, difficult to load and view the blue ocean and
> > other
> > > >Jenkins build status page.
> > > >2. We are generating too many request/interaction on Apache Infra
> > > team.
> > > >   1. Addition/deletion of new slave: Caused from scaling
> activity,
> > > >   recycling, troubleshooting or any actions leading to change of
> > > slave
> > > >   machines.
> > > >   2. Plugins / other Jenkins Master configurations.
> > > >   3. Experimentation on CI pipelines.
> > > >3. Harder to debug and resolve issues - Since access to master and
> > > slave
> > > >is not with the same community, it requires Infra and community to
> > > dive
> > > >deep together on all action items.
> > > >
> > > > Possible Solutions:
> > > >
> > > > ==
> > > >
> > > >1. Can we set up a separate Jenkins CI build system for Apache
> MXNet
> > > >outside Apache Infra?
> > > >2. Can we have a separate Jenkins Master in Apache Infra for
> MXNet?
> > > >3. Review design of current setup, refine and fill the gaps.
> > > >
> > > > @ Mentors/Infra team/Community:
> > > >
> > > > ==
> > > >
> > > > Please provide your suggestions on how we can proceed further and
> work
> > on
> > > > stabilizing the CI build systems for MXNet.
> > > >
> > > > Also, if the community decides on separate Jenkins CI build system,
> > what
> > > > important points should be taken care of apart from the below:
> > > >
> > > >1. Community being able to access the build page for build
> statuses.
> > > >2. Committers being able to login with apache credentials.
> > > >3. Hook setup from apache/incubator-mxnet repo to Jenkins master.
> > > >
> > > >
> > > > Irrespective of the solution we come up, I think we should initiate a
> > > > technical design discussion on how to setup the CI build system.
> > > Probably 1
> > > > or 2 pager documents with the architecture and review with Infra and
> > > > community members.
> > > >
> > > > ***There were few proposal and discussion on the slack channel, to
> > reach
> > > > wider community members, moving that discussion formally to this
> list.
> > > >
> > > >
> > > > My Proposal: Option 1 - Set up separate Jenkins CI build system.
> > > >
> > > > Thanks,
> > > >
> > > > Sandeep
> > > >
> > > >
> > > >
> > > > --
> > > > Sandeep Krishnamurthy
> > > >
> > >
> >
>

[RESULT][VOTE] Release Apache MXNet (incubating) Version 0.12.0.rc0

[Meghna Baijal]

Hi All,
The vote for releasing Apache MXNet (incubating) 0.12.0 RC0 passed with the
following result -

+1 binding
- Chris Olivier
- Suneel Marthi
- Indhu Bharathi

+1 non-binding
- Gautam Kumar

There was no -1 and 0

Vote thread :
https://lists.apache.org/thread.html/800402860be8a1b4055ede075ab465af48b7f8d041b42217372a63b9@%3Cdev.mxnet.apache.org%3E

I am now going to create a vote on the general@ list.

Thanks,
Meghna Baijal

Re: [VOTE] Release MXNet version 0.12.0.rc0

[Meghna Baijal]

I verified again, on an ubuntu instance this time. Worked without the ‘g’

sha512sum --check  ./apache-mxnet-src-0.12.0.rc0-incubating.tar.gz.sha512

On Fri, Oct 20, 2017 at 10:16 PM, Sebastian <ssc.o...@googlemail.com> wrote:

> Hmm, still doesn't work. Looks like the download of
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.12.0.rc0
> /apache-mxnet-src-0.12.0.rc0-incubating.tar.gz.sha512 has some problems
> on my machine, I can't view the file contents, maybe a problem with the
> content-type?
>
>
> On 21.10.2017 07:01, Meghna Baijal wrote:
>
>> Hi Sebastian,
>> Can you try the following:
>> gsha512sum --check  ./apache-mxnet-src-0.12.0.rc0-
>> incubating.tar.gz.sha512
>> This worked for me.
>>
>> Thanks,
>> Meghna Baijal
>>
>> On Oct 20, 2017 9:53 PM, "Sebastian" <ssc.o...@googlemail.com> wrote:
>>
>> Verifying the sha512 sig didn't work for me, what am I doing wrong here?
>>
>> sha512sum -c apache-mxnet-src-0.12.0.rc0-incubating.tar.gz.sha512
>> sha512sum: apache-mxnet-src-0.12.0.rc0-incubating.tar.gz.sha512: no
>> properly formatted SHA512 checksum lines found
>>
>>
>> On 21.10.2017 02:36, Suneel Marthi wrote:
>>
>> +1 binding
>>>
>>> 1. Checked Sigs and hashes
>>> 2. has -incubating in artifact name
>>>
>>>
>>> On Fri, Oct 20, 2017 at 8:34 PM, Chris Olivier <cjolivie...@gmail.com>
>>> wrote:
>>>
>>> +1
>>>
>>>>
>>>>
>>>> On Fri, Oct 20, 2017 at 5:01 PM Meghna Baijal <
>>>> meghnabaijal2...@gmail.com
>>>>
>>>>>
>>>>> wrote:
>>>>
>>>> This is the vote to release Apache MXNet (incubating) version 0.12.0.
>>>>
>>>>>
>>>>> Voting will start now (Friday, October 20, 2017 11:55PM UTC) and
>>>>>
>>>>> close Tuesday, October 24, 2017 11:55PM UTC.
>>>>>
>>>>>
>>>>> Link to release notes:
>>>>>
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/MXNET/
>>>>>
>>>>> MXNet+0.12.0+Release+Notes
>>>>
>>>>
>>>>>
>>>>> Link to release candidate 0.12.0.rc0:
>>>>>
>>>>> https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.12.0.rc0/
>>>>>
>>>>>
>>>>> View this page and scroll down to “Build from Source” to build this
>>>>> project:
>>>>>
>>>>> http://mxnet.incubator.apache.org/get_started/install.html
>>>>>
>>>>>
>>>>> The release tag can be found here:
>>>>>
>>>>> https://github.com/apache/incubator-mxnet/tree/0.12.0.rc
>>>>> <https://github.com/apache/incubator-mxnet/tree/0.12.0.rc0>0
>>>>>
>>>>> (Note: The README.md points to the 0.12.0 tag and does not work at the
>>>>> moment.)
>>>>>
>>>>>
>>>>> Please make sure you TEST before you vote accordingly:
>>>>>
>>>>>
>>>>> +1 = approve
>>>>>
>>>>>
>>>>> +0 = no opinion
>>>>>
>>>>>
>>>>> -1 = disapprove (provide reason)
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Meghna Baijal
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>

Re: [VOTE] Release MXNet version 0.12.0.rc0

[Meghna Baijal]

Hi Sebastian,
Can you try the following:
gsha512sum --check  ./apache-mxnet-src-0.12.0.rc0-incubating.tar.gz.sha512
This worked for me.

Thanks,
Meghna Baijal

On Oct 20, 2017 9:53 PM, "Sebastian" <ssc.o...@googlemail.com> wrote:

Verifying the sha512 sig didn't work for me, what am I doing wrong here?

sha512sum -c apache-mxnet-src-0.12.0.rc0-incubating.tar.gz.sha512
sha512sum: apache-mxnet-src-0.12.0.rc0-incubating.tar.gz.sha512: no
properly formatted SHA512 checksum lines found


On 21.10.2017 02:36, Suneel Marthi wrote:

> +1 binding
>
> 1. Checked Sigs and hashes
> 2. has -incubating in artifact name
>
>
> On Fri, Oct 20, 2017 at 8:34 PM, Chris Olivier <cjolivie...@gmail.com>
> wrote:
>
> +1
>>
>>
>> On Fri, Oct 20, 2017 at 5:01 PM Meghna Baijal <meghnabaijal2...@gmail.com
>> >
>> wrote:
>>
>> This is the vote to release Apache MXNet (incubating) version 0.12.0.
>>>
>>> Voting will start now (Friday, October 20, 2017 11:55PM UTC) and
>>>
>>> close Tuesday, October 24, 2017 11:55PM UTC.
>>>
>>>
>>> Link to release notes:
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/MXNET/
>>>
>> MXNet+0.12.0+Release+Notes
>>
>>>
>>>
>>> Link to release candidate 0.12.0.rc0:
>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.12.0.rc0/
>>>
>>>
>>> View this page and scroll down to “Build from Source” to build this
>>> project:
>>>
>>> http://mxnet.incubator.apache.org/get_started/install.html
>>>
>>>
>>> The release tag can be found here:
>>>
>>> https://github.com/apache/incubator-mxnet/tree/0.12.0.rc
>>> <https://github.com/apache/incubator-mxnet/tree/0.12.0.rc0>0
>>>
>>> (Note: The README.md points to the 0.12.0 tag and does not work at the
>>> moment.)
>>>
>>>
>>> Please make sure you TEST before you vote accordingly:
>>>
>>>
>>> +1 = approve
>>>
>>>
>>> +0 = no opinion
>>>
>>>
>>> -1 = disapprove (provide reason)
>>>
>>>
>>> Thanks,
>>>
>>> Meghna Baijal
>>>
>>>
>>
>

Re: Build cancellations

[Meghna Baijal]

Hello All,
Jenkins CI seems to be stable. If your build was terminated by someone over
the last couple of days, you can trigger it now by pushing an empty commit
to the same branch or manually in Jenkins if you have access.

Thanks,
Meghna Baijal

On Thu, Oct 19, 2017 at 12:04 PM, Chris Olivier <cjolivie...@gmail.com>
wrote:

> Hi all,
>
> We are having lots of problems with CI yesterday and still today.  It is
> very likely that if you have a PR, the build will get cancelled in an
> effort to diagnose and remedy the situation. I apologize in advance for
> this.
>
> -Chris
>

[VOTE] Release MXNet version 0.12.0.rc0

[Meghna Baijal]

This is the vote to release Apache MXNet (incubating) version 0.12.0.

Voting will start now (Friday, October 20, 2017 11:55PM UTC) and

close Tuesday, October 24, 2017 11:55PM UTC.


Link to release notes:

https://cwiki.apache.org/confluence/display/MXNET/MXNet+0.12.0+Release+Notes


Link to release candidate 0.12.0.rc0:

https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.12.0.rc0/


View this page and scroll down to “Build from Source” to build this project:

http://mxnet.incubator.apache.org/get_started/install.html


The release tag can be found here:

https://github.com/apache/incubator-mxnet/tree/0.12.0.rc
<https://github.com/apache/incubator-mxnet/tree/0.12.0.rc0>0

(Note: The README.md points to the 0.12.0 tag and does not work at the
moment.)


Please make sure you TEST before you vote accordingly:


+1 = approve


+0 = no opinion


-1 = disapprove (provide reason)


Thanks,

Meghna Baijal

Release plan - Apache MXNet (incubating) 0.12.0

[Meghna Baijal]

I am starting the process to prepare for Apache MXNet (incubating) 0.12.0
Release. I have drafted the release notes (link)
<https://cwiki.apache.org/confluence/display/MXNET/MXNet+0.12.0+Release+Notes>
 to cover the tasks under this release.
A release candidate will be cut on Monday, October 16th and voting will
commence from then until Friday, October 20th. If you have any additional
features in progress and would like to include it in this release, please
make sure they have been merged by Friday, October 13, 2017 10:00 PM UTC
and comment so I may update the release notes.

Feel free to add any other comments/suggestions.
Thanks,
Meghna Baijal

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

[Meghna Baijal]

Hi Jason,
I did go through some of Beam’s source code but did not find any way to
overcome my current problem. Could you please point me in the right
direction?

Thanks,
Meghna Baijal

On Thu, Sep 28, 2017 at 10:32 AM, Daniel Pono Takamori <p...@apache.org>
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 <mnnav...@gmail.com> 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 <
> meghnabaijal2...@gmail.com>
> > 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: 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 
<https://github.com/apache/incubator-mxnet/pull/8078>

Thanks,
Meghna Baijal
> On Sep 28, 2017, at 10:32 AM, Daniel Pono Takamori <p...@apache.org> 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 <mnnav...@gmail.com> 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 <meghnabaijal2...@gmail.com>
>> 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
>>> 
>>> 

PR builds are currently failing due to a known issue

[Meghna Baijal]

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: MXNet Build Services

[Meghna Baijal]

Hello Daniel, 
Thank you for reaching out to us with your concerns. I do understand your 
points and apologize for not following the correct procedures. 
We are making every attempt to address these issues. For starters, 
1. We are directing our build related queries to the bui...@apache.org 
 mailing list.
2. Opening JIRA tickets to get help from the Apache Infra team. 
3. And we have created a “builds" channel on the MXNet Slack workspace 
(apache-mxnet.slack.com ). We now have all our 
builds related discussions on this channel and anyone can subscribe to it. I 
hope this helps improve communication between our teams.

 
Thanks,
Meghna

> On Sep 21, 2017, at 12:05 PM, Daniel Pono Takamori  wrote:
> 
> Hello MXNet Team,
> I wanted to send an email to check in on your build services and make
> sure we're on the same page when it comes to the MXNet project and
> Apache Infrastructure.  As I'm sure you are aware the ASF has over 200
> active projects and plenty more subprojects that we shepard. Coming
> from the infra side of things, this can often make it overwhelming to
> understand and work with the multitude of needs these projects
> possess.
> 
> When MXNet was onboarding into the the Incubator I tried my best to
> facilitate the transition and as such made myself readily available to
> your team members who asked for it.  This might have been a mistake as
> I didn't make it clear that I was giving priority to your project to
> get you up to speed.  As it stands now it seems that your team might
> think I'm the only infra member which can help them!  On the contrary
> we have a great team of 5 people who are equally if not more
> knowledgeable than I am.
> 
> The places to reach our team are on Hipchat, where we can try to be
> real time but given workloads sometimes that's not possible, email
> us...@infra.apache.org for general infrastructure questions and
> bui...@apache.org for specific questions.  But most importantly is the
> JIRA instance https://issues.apache.org/jira/browse/INFRA  This is
> where you can file tickets when you need help with things and we will
> be able to look at them and work on them as our workload enables us to
> (keep in mind we cannot respond instantly to each of 200 projects so
> you'll have to bear with us).
> 
> Now onto the more technical side of things.  As you are hosting your
> own build nodes and connecting them to our jenkins we can only do the
> adding and renaming, etc.  Recently with
> https://issues.apache.org/jira/browse/INFRA-15114  it came up that
> there is some backend tooling at Amazon that Apache Infra was
> completely unaware of.  It would definitely help all of us involved if
> you keyed us into the overall design of your setup that way it didn't
> seem like every single request in Hipchat was of utmost urgency.
> Browsing the dev@mxnet list I haven't been able to find much
> information about the build setup so I'm not sure where those
> conversations are happening.
> 
> To summarize:
> 1).  The ASF is a huge organization and cannot give preferred
> treatment to projects.
> 2).  I (Pono) am not the only Infra member that can help you
> 3). JIRA is the best place to get our teams attention for work items
> 4).  Discussion about your build system should be more transparent and
> certainly include the Infra team.
> 
> Thanks for listening and good luck Incubating!
> -Daniel Pono Takamori

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

[Meghna Baijal]

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

Re: [ANNOUNCE] Apache MXNet (incubating) 0.11.0 Release

[Meghna Baijal]

Thank you for your suggestion! I have updated our release process wiki to 
reflect your point and we will make sure to incorporate next time. 

- Meghna

> On Sep 7, 2017, at 4:16 AM, sebb  wrote:
> 
> What is the project about? Why should I be interested in it?
> [rhetorical questions]
> 
> The Announce emails are sent to people not on the developer or user lists.
> Most will have no idea what the project is about.
> 
> So the e-mails should contain at least brief details of what the
> product does, and some info on why the new release might be of
> interest to them.
> 
> Readers should not have to click the link to find out the basic information
> (although of course it is useful to have such links for further detail).
> 
> Please can you add that information to future announce mails?
> 
> Thanks.
> 
> 
> On 7 September 2017 at 03:06, Naveen Swamy  wrote:
>> The Apache MXNet community is happy to announce Apache MXNet version 0.11.0!
>> We hit some major milestones with this release!
>> This is our first official release as an incubating Apache project. The
>> project has now fully migrated its code base and website to Apache.
>> This release includes code contributions from developers from Apple,
>> Samsung, Microsoft and many other.
>> We have also crossed over 400 contributors on the project so far. The 0.11.0
>> release features Apple Core ML model converter, Support for Keras v1.2.2.
>> 
>> A blog that explains an end to end use case of building an ios app using
>> MXNet and Core ML:
>> https://aws.amazon.com/blogs/ai/bring-machine-learning-to-ios-apps-using-apache-mxnet-and-apple-core-ml/
>> 
>> The AWS blog that highlights the key features of the release:
>> https://aws.amazon.com/blogs/ai/apple-core-ml-and-keras-support-now-available-for-apache-mxnet/
>> 
>> A full list of the changes in this release can be found in the release
>> notes:
>> https://cwiki.apache.org/confluence/display/MXNET/MXNet+0.11.0+Release+Notes
>> 
>> 
>> Link to Download: http://www.apache.org/dist/incubator/mxnet/
>> 
>> 
>> To build this project, view this page and select “Build from Source”:
>> http://mxnet.incubator.apache.org/get_started/install.html
>> 
>> 
>> The Docker Images can be found here:
>> https://hub.docker.com/u/mxnet/ 
>> 
>> The Pip package can be found here:
>> https://pypi.python.org/pypi/mxnet 
>> 
>> The Release Tag is here:
>> https://github.com/apache/incubator-mxnet/tree/0.11.0
>> 
>> 
>> MXNet Resources
>>   - Issues: https://github.com/apache/incubator-mxnet/issues
>> 
>>   - Wiki: https://cwiki.apache.org/confluence/display/MXNET
>> 
>>   - Mailing list(s): dev@mxnet.incubator.apache.org
>> 
>> 
>> For more information on Apache MXNet, please see:
>> https://mxnet.incubator.apache.org/ 
>> 
>> Thanks!
>> Apache MXNet(incubating) Team
>> ___
>> 
>> DISCLAIMER:
>> Apache MXNet (incubating) is an effort undergoing incubation at The
>> Apache Software Foundation (ASF), sponsored by the name of Apache
>> Incubator PMC. Incubation is required of all newly accepted
>> projects until a further review indicates that the
>> infrastructure, communications, and decision-making process have
>> stabilized in a manner consistent with other successful ASF
>> projects. While incubation status is not necessarily a reflection
>> of the completeness or stability of the code, it does indicate
>> that the project has yet to be fully endorsed by the ASF.

Re: [VOTE] Apache MXNet (incubating) 0.11.0 release RC3

[Meghna Baijal]

Thanks John. I will create the JIRA tickets to track your inputs as requested. 

Meghna
 
> On Aug 29, 2017, at 6:14 PM, John D. Ament <johndam...@apache.org> wrote:
> 
> Ok, so here's my +1 to release, with the following notes:
> 
> - The NOTICE file is wrong.  Unless the dependencies listed have explicit
> notice requirements (they don't seem to) nothing needs to be added to the
> NOTICE file.
> - The source headers should be reverted in any areas where not all
> contributors to that file have signed ICLAs, otherwise we need some kind of
> agreement they are OK with moving to NOTICE file (which is how this has
> been handled in the past).
> 
> Please create JIRAs to track these.
> 
> John
> 
> On Tue, Aug 29, 2017 at 9:09 PM Henri Yandell <bay...@apache.org 
> <mailto:bay...@apache.org>> wrote:
> 
>> I believe all the major contributors were ICLA'd, and I disagree that all
>> contributors need to SGA/ICLA; we don't do that for an existing project.
>> 
>> We need to do the check to see how the footprint of contributions for the
>> largest contributor without an ICLA is (apologies for the horrible wording
>> there). There are over 400 contributors, but (quickly eyeballing) most are
>> covered by ICLA or small contributions. Note that we also have clause 5 of
>> Apache 2.0 at play for historical contributions here.
>> 
>> To John's point on source headers; the previous source headers said
>> "Copyright  by Contributors".
>> 
>> Hen
>> 
>> On Tue, Aug 29, 2017 at 11:01 Craig Russell <apache@gmail.com> wrote:
>> 
>>> Hi Henri,
>>> 
>>> If a project was developed outside Apache then everyone who contributed
>> to
>>> the project has to have an ICLA on file or file a Software Grant as part
>> of
>>> IP Clearance.
>>> 
>>> It's not sufficient that the code has always been under the ASL 2.0.
>>> 
>>> Are there any contributors to the project before it came to the incubator
>>> who are not now committers?
>>> 
>>> Regards,
>>> 
>>> Craig
>>> 
>>>> On Aug 29, 2017, at 9:43 AM, Henri Yandell <bay...@apache.org> wrote:
>>>> 
>>>> Apologies - I missed that mentors hadn't voted on the podling release.
>>> Will
>>>> review tonight; hopefully their mentors can do similar.
>>>> 
>>>> There's no reason for an SGA here (and who would even sign it?). Code
>> has
>>>> been apache 2.0 since the initial commit on GitHub.
>>>> 
>>>> On Tue, Aug 29, 2017 at 06:45 John D. Ament <johndam...@apache.org>
>>> wrote:
>>>> 
>>>>> Dominic,
>>>>> 
>>>>> One question, from looking a second time.  Was MXNet always Apache
>>> Licensed
>>>>> (prior to coming to the ASF)?
>>>>> 
>>>>> John
>>>>> 
>>>>> On Tue, Aug 29, 2017 at 8:39 AM Dominic Divakaruni <
>>>>> dominic.divakar...@gmail.com> wrote:
>>>>> 
>>>>>> Thanks for the reply, John. None of the mentors have voted so far.
>>>>>> Henri, Suneel, Marcus, Sebastian, can you gents please review and
>> vote?
>>>>>> 
>>>>>> Also, Henri, didn't you mention that there was an SGA for this
>> project?
>>>>>> Sorry if I don't recollect the exact details on the SGA bit.
>>>>>> 
>>>>>> Dom
>>>>>> 
>>>>>> 
>>>>>> On Tue, Aug 29, 2017 at 5:27 AM, John D. Ament <
>> johndam...@apache.org>
>>>>>> wrote:
>>>>>> 
>>>>>>> Non pmc members can vote non-binding.  Usually mentors review
>>> releases.
>>>>>>> Have any of your mentors reviewed and voted on it?  Due to there
>> being
>>>>> no
>>>>>>> SGA its a harder release to review.  I also need to cross check
>> ICLAs
>>>>> and
>>>>>>> files that have changed license.
>>>>>>> 
>>>>>>> On Aug 29, 2017 8:13 AM, "Dominic Divakaruni" <
>>>>>>> dominic.divakar...@gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Can this vote pass without the three +1's from the PMC? Can the
>>>>>>> committers
>>>>>>>> for this project provide binding votes on ge

[RESULT][VOTE] Release MXNet version 0.11.0.rc3

[Meghna Baijal]

Hi All, 
The vote for releasing Apache MXNet (incubating) 0.11.0 RC3 passed with the 
following result - 

+1 binding
- Chris Olivier 
- Naveen Swamy 
- Sandeep Krishnamurthy 

+1 non-binding
- Gautam Kumar

There was no -1 and 0 

Vote thread :
https://lists.apache.org/thread.html/2695a598ae0622484d4c886dc5b2ea823c306ca4ebef66accec6ee76@%3Cdev.mxnet.apache.org%3E
 


I am now going to create a vote in the general@ list.

Thanks.

[VOTE] Release MXNet version 0.11.0.rc3

[Meghna Baijal]

This is the vote to release Apache MXNet (incubating) version 0.11.0.
Voting will start now (Thursday, August 24, 2017 9:50 PM UTC) and
close Monday, August 28, 2017 9:50 PM UTC or when we have 
received 3 +1 votes.

Link to release notes:
https://cwiki.apache.org/confluence/display/MXNET/v0.11.0+Release+Notes+-+MXNet+v0.11+Release+Candidate
 


Link to release candidate 0.11.0.rc3:
https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.11.0.rc3/ 


View this page and scroll down to “Build from Source” to build this project:
http://mxnet.incubator.apache.org/get_started/install.html 


The release tag can be found here: 
https://github.com/apache/incubator-mxnet/tree/0.11.0.rc3 


Changes between rc2 and rc3:
1. Consolidated and Updated the LICENSE and NOTICE Files
2. Fixed image-classification example

Major Features in v0.11.0:
1. CoreML Converter: 
https://github.com/apache/incubator-mxnet/blob/master/tools/coreml/README.md 

2. Keras 1.2.2 Support: https://github.com/dmlc/keras/wiki/Installation 

3. Gluon Interface (experimental): 
https://github.com/apache/incubator-mxnet/blob/v0.11.0/docs/api/python/gluon.md 



Please make sure you TEST before you vote accordingly:

+1 = approve

+0 = no opinion

-1 = disapprove (provide reason)

Re: [VOTE][CANCELLED]Release MXNet version 0.11.0.rc1

[Meghna Baijal]

We are closing this vote because there is a bug causing 20-30% performance 
degradation.

We will address this issue and send out RC2 for another vote.
> On Aug 14, 2017, at 7:25 PM, Meghna Baijal <meghnabaijal2...@gmail.com> wrote:
> 
> This is the vote to release Apache MXNet (incubating) version 0.11.0.
> Voting will start now (Tuesday, August 15, 2017 2:25 AM UTC) and
> close Friday, August 18, 2017 2:25 AM UTC.
> 
> Link to release notes:
> https://cwiki.apache.org/confluence/display/MXNET/v0.11.0+Release+Notes 
> <https://cwiki.apache.org/confluence/display/MXNET/v0.11.0+Release+Notes>
> 
> Link to release candidate 0.11.0.rc1:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.11.0.rc1/ 
> <https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.11.0.rc1/>
> 
> View this page and scroll down to “Build from Source” to build this project:
> http://mxnet.incubator.apache.org/get_started/install.html 
> <http://mxnet.incubator.apache.org/get_started/install.html>
> 
> Changes between rc0 and rc1:
> 1. Updated NOTICE File 
> 2. Tarball now contains all the submodule code
> 3. Updated CoreML Readme for usability and a known issue
> 
> Major Features in v0.11:
> 1. CoreML Converter: 
> https://github.com/apache/incubator-mxnet/blob/master/tools/coreml/README.md 
> <https://github.com/apache/incubator-mxnet/blob/master/tools/coreml/README.md>
> 2. Keras 1.2.2 Support: https://github.com/dmlc/keras/wiki/Installation 
> <https://github.com/dmlc/keras/wiki/Installation>
> 
> 
> 
> Please make sure you TEST before you vote accordingly:
> 
> +1 = approve
> 
> +0 = no opinion
> 
> -1 = disapprove (provide reason)

[VOTE] Release MXNet version 0.11.0.rc1

[Meghna Baijal]

This is the vote to release Apache MXNet (incubating) version 0.11.0.
Voting will start now (Tuesday, August 15, 2017 2:25 AM UTC) and
close Friday, August 18, 2017 2:25 AM UTC.

Link to release notes:
https://cwiki.apache.org/confluence/display/MXNET/v0.11.0+Release+Notes 


Link to release candidate 0.11.0.rc1:
https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.11.0.rc1/ 


View this page and scroll down to “Build from Source” to build this project:
http://mxnet.incubator.apache.org/get_started/install.html 


Changes between rc0 and rc1:
1. Updated NOTICE File 
2. Tarball now contains all the submodule code
3. Updated CoreML Readme for usability and a known issue

Major Features in v0.11:
1. CoreML Converter: 
https://github.com/apache/incubator-mxnet/blob/master/tools/coreml/README.md 

2. Keras 1.2.2 Support: https://github.com/dmlc/keras/wiki/Installation 




Please make sure you TEST before you vote accordingly:

+1 = approve

+0 = no opinion

-1 = disapprove (provide reason)

Re: [VOTE][CLOSED]Release MXNet version 0.11.0

[Meghna Baijal]

We are closing this vote for the following issues - 
1. Missing statements in the NOTICE File
2. Missing submodule source code
3. Needed improvements such as grammatical errors in the README File
4. CoreML converter: Out of around 10 models tested, inceptionv3 fails on the 
iPhone app even though other inception models successfully go through.
5. CoreML converter: The label names provided in the arguments for the 
converter seem to be having no effect on the iPhone app. It works with or 
without them but IIRC they did seem to show effect during our unit testing.

We will address these issues and send out RC1 for another vote.

> On Aug 12, 2017, at 4:18 AM, shiwen hu  wrote:
> 
> +1
> 
> 2017-08-12 19:16 GMT+08:00 Chris Olivier :
> 
>> +1
>> 
>> On Sat, Aug 12, 2017 at 2:28 AM Ly Nguyen  wrote:
>> 
>>> This is the vote to release Apache MXNet (incubating) version 0.11.0.
>>> Voting will start now (Saturday, August 12, 2017 9:26 AM UTC) and
>>> close Tuesday, August 15, 2017 9:26 AM UTC.
>>> 
>>> Link to release notes:
>>> https://cwiki.apache.org/confluence/display/MXNET/v0.11.0+Release+Notes
>>> 
>>> Link to release candidate 0.11.0.rc0:
>>> https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.11.0.rc0/
>>> 
>>> 
>>> 
>>> Please test and vote accordingly:
>>> 
>>> +1 = approve
>>> 
>>> +0 = no opinion
>>> 
>>> -1 = disapprove (provide reason)
>>> 
>>