Re: Release plan - MXNET 1.0.1

2018-01-26 Thread Haibin Lin 
Hi everyone,

Just some status update:

1. The two tests reported in #9553 are both fixed by @anirudh2290.

2. Many broken website links are fixed in #9575 by @thinksanky.

3. I made some updates to the release note. Please help edit the note and
so that it reflects all changes in MXNet including new functionalities in
the contrib namespace.


Best,
Haibin

On Thu, Jan 25, 2018 at 6:26 PM, Haibin Lin 
wrote:

> Hi everyone,
>
> Just some status update regarding the release:
>
> 1. More license fixes by @mbaijal are merged.
> https://github.com/apache/incubator-mxnet/pull/9554 for the perl package
> https://github.com/apache/incubator-mxnet/pull/9556 for the docs folder
> https://github.com/apache/incubator-mxnet/pull/9559 for the ci_build
> folder
>
> 2. Two tests failed intermittently, reported by @marcoabreu in another
> thread. We(@anirudh2290 and I) are looking into them.
> - test_operator_gpu.test_correlation
> 
> There were no changes for the test and implementation of this operator for
> the past two months. Is anyone using this operator? We are currently trying
> to reproduce the error.
> - test_forward.test_consistency
> 
> It looks like the downloaded numpy file is truncated. We'll make a PR to
> update the test.
>
> 3. More API changes since 1.0.0 reported by @szha
> - https://github.com/apache/incubator-mxnet/pull/9040
> 
> - https://github.com/apache/incubator-mxnet/pull/9420
> 
> - https://github.com/apache/incubator-mxnet/pull/9306
>
> Best,
> Haibin
>
> On Thu, Jan 25, 2018 at 8:08 AM, Steffen Rochel 
> wrote:
>
>> I support the proposal from Nan - this is a practical and productive way.
>> I
>> include Nan's description into
>> https://cwiki.apache.org/confluence/display/MXNET/Release+Ve
>> rsioning+and+Branching
>>
>>
>> We should make API changes very carefully and need to depend on the
>> community to flag any changes until we have better test coverage.
>>
>> Steffen
>>
>> On Thu, Jan 25, 2018 at 7:30 AM kellen sunderland <
>> kellen.sunderl...@gmail.com> wrote:
>>
>> > @Marco: Ok, well then it sounds like a good time for the community to
>> > re-think how we look for API changes ;-).  We can continue the chat in
>> the
>> > semver proposal, but maybe we could create a collection of APIs we
>> consider
>> > to be semver'd and review those interfaces each release.  Spending
>> reviewer
>> > and contributor time each PR on something that we ultimately ignore
>> doesn't
>> > seem productive.
>> >
>> > On Thu, Jan 25, 2018 at 4:29 PM, kellen sunderland <
>> > kellen.sunderl...@gmail.com> wrote:
>> >
>> > > Yes this is also what I'd suggest Nan, sorry if I wasn't clear.  My
>> > > comment was referring to 2.  So as an example for our current release
>> we
>> > > could cut a new minor release including new features such as the text
>> > api,
>> > > scala rename, but we could cherry-pick the important bug fixes and
>> apply
>> > > them to the 1.0.x branch.
>> > >
>> > > On Thu, Jan 25, 2018 at 4:22 PM, Nan Zhu 
>> wrote:
>> > >
>> > >> regarding "I'd agree that we should apply most of the fixes to the
>> > >> previous
>> > >> release branch and build from there."
>> > >>
>> > >> my suggestion is actually a bit different with this, my idea is that
>> > >>
>> > >> 1. we always work with master branch, and when there is a date for
>> > >> releasing a new version (minor or major) one, we cut a new branch and
>> > >> announce code freeze for that version (of course, there is some
>> > exception
>> > >> to merge the previously-ignored blockers to the newly cut branch)
>> > >>
>> > >> 2. after the release, we still work in master for the next (at least
>> > minor
>> > >> version) and cautiously backport the patches to the last cut branch
>> > >> (assuming that we always maintain only one previous minor version)
>> > >>
>> > >> with this model, what we would do now is cut a new 1.1 branch for the
>> > >> coming release, if it is necessary to have a maintenance version, we
>> > would
>> > >> cherry-pick the important and backward-compatible fixes to 1.0.x
>> branch
>> > >> (though ideally this should be done when merging fixes to master )
>> > >>
>> > >> Best,
>> > >>
>> > >> Nan
>> > >>
>> > >>
>> > >>
>> > >> On Thu, Jan 25, 2018 at 2:01 AM, kellen sunderland <
>> > >> kellen.sunderl...@gmail.com> wrote:
>> > >>
>> > >> > -.5 (non-binding) to releasing as a minor release.  If we don't
>> have
>> > any
>> > >> > breaking API changes, and we haven't added any major features I
>> would
>> > >> tend
>> > >> > to release this as a patch release.  The reason being that
>> > organizations
>> > >> > and users will

Re: Refactoring MXNet scala code to use "org.apache.mxnet"

2018-01-26 Thread Naveen Swamy 
Since this change from ml.dmlc to org.apache is breaking and not backward
compatible, it requires a major version upgrade, I reverted the change
https://github.com/apache/incubator-mxnet/pull/9579.

I think It warrants a separate discussion on how to manage release
lifecycles of the various language bindings of MXNet.

-Naveen

On Thu, Jan 11, 2018 at 1:53 PM, YiZhi Liu  wrote:

> Since we now have changed package prefix to org.apache, does someone have
> guidance for posting it to Apache's Maven Repository?
>
> ml.dmlc.mxnet was posted to oss.sonatype.org.
>
> 2018-01-04 17:14 GMT-08:00 Lupesko, Hagay :
>
> > Suneel,
> >
> > I tend to think for this issue, GitHub issue is good enough and we do not
> > need JIRA.
> > Can you clarify what is the advantage you see in using JIRA over GitHub
> > issue for this specific case?
> >
> > Thanks!
> > Hagay
> >
> > On 1/4/18, 16:34, "Suneel Marthi"  wrote:
> >
> > Jira has been around for a while -
> > https://issues.apache.org/jira/projects/MXNET/
> >
> > switch to using jira
> >
> > On Thu, Jan 4, 2018 at 7:31 PM, Roshani Nagmote <
> > roshaninagmo...@gmail.com>
> > wrote:
> >
> > >  Hi,
> > >
> > > As currently, MXNet does not have Jira project, I have created
> > github issue
> > > for now.
> > > https://github.com/apache/incubator-mxnet/issues/9315
> > >
> > > Will create the PR and link the issue there.
> > >
> > > Thanks,
> > > Roshani
> > >
> > > On Thu, Jan 4, 2018 at 3:08 PM, Naveen Swamy 
> > wrote:
> > >
> > > > Hi Suneel,
> > > >
> > > > Did we decide that we will using Jira going forward? If not, can
> > someone
> > > > summarize on the improvement email on the consensus and lets make
> > it
> > > > universal and how to use it, what is expected, etc.,
> > > >
> > > > For the record, I like the idea of using Jira for more openness.
> > > >
> > > > Also, MXNet does not have Jira project, can you help creating
> one?
> > > >
> > > > Thanks, Naveen
> > > >
> > > >
> > > > On Thu, Jan 4, 2018 at 2:35 PM, Suneel Marthi <
> smar...@apache.org>
> > > wrote:
> > > >
> > > > > Is there a Jira for this? Please create a Jira and reference
> > that in
> > > the
> > > > PR
> > > > > for this.
> > > > >
> > > > > On Thu, Jan 4, 2018 at 5:16 PM, Roshani Nagmote <
> > > > roshaninagmo...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Hello all,
> > > > > >
> > > > > > I am working on publishing mxnet-scala release to maven
> > repository
> > > and
> > > > > as a
> > > > > > part of that, I will also be refactoring mxnet-scala
> > > code/tests/example
> > > > > and
> > > > > > docs to use "org.apache.mxnet" instead of "ml.dmlc.mxnet".
> > > > > >
> > > > > > Currently, MXNet-Scala
> > > > > > 
> > library
> > > uses
> > > > > > "ml.dmlc.mxnet" packages. This work will change the way to
> > import
> > > > modules
> > > > > > when using mxnet-scala package.
> > > > > >
> > > > > > *Old way:*
> > > > > >
> > > > > > scala> import ml.dmlc.mxnet._
> > > > > >import ml.dmlc.mxnet._scala> val arr = NDArray.ones(2, 3)
> > > > > >arr: ml.dmlc.mxnet.NDArray =
> ml.dmlc.mxnet.NDArray@f5e74790
> > > > > >
> > > > > > *New way:*
> > > > > >
> > > > > > scala> import org.apache.mxnet._
> > > > > >import org.apache.mxnet._
> > > > > > scala> val arr = NDArray.ones(2, 3)
> > > > > >arr: org.apache.mxnet.NDArray = org.apache.mxnet.NDArray@
> > f5e74790
> > > > > >
> > > > > >
> > > > > > Please let me know if anyone has any thoughts or issues with
> > this
> > > > change.
> > > > > >
> > > > > > Thanks,
> > > > > > Roshani
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> >
>
>
> --
> Yizhi Liu
> DMLC member
> Amazon Web Services
> Vancouver, Canada
>

Re: Please help update/review pending PRs

2018-01-26 Thread Pedro Larroy 
I would like to get these merged for the release, is it too late?


https://github.com/dmlc/mshadow/pull/322
https://github.com/dmlc/dmlc-core/pull/357

On Mon, Jan 22, 2018 at 9:01 PM, Haibin Lin  wrote:
> Hi everyone,
>
> We still have a long list of outstanding PRs on GitHub. Contributors who
> created the PR, could you all check your PR's status and resolve review
> comments if any? Can everyone help review the pending PRs?
>
> Best,
> Haibin
>
> === list of open PRs on github =
>
> zhanghang1989   7938
> anirudh2290 8000 8738 9373
> fhieber 8027
> solin3198107 8423
> yajiedesign 8114
> kli-nlpr8218
> benqua  8245
> kevinthesun 8254
> zheng-da8302
> szha8377 9514
> crazy-cat   8437
> Prasad9 8484
> DickJC123   8526
> azai91  8527
> munkim  8547
> larroy  8578 8872 9035 9457
> zhreshold   8582 8639
> eftiquar8619
> ptrendx 8652
> xinghedyc   8797
> wonghang8845
> weixingzhang8849
> joeddav 8912
> Laurawly8915
> ashokei 8918
> eric-haibin-lin 8922 9481
> taliesinb   8949
> cjolivier01 8972 9498
> rahul0039029 9049 9152
> mbaijal 9046 9484 9500 9504 9505
> anjishnu9111
> jegalgo 9142
> chaoyuaw9165
> zihaolucky  9195
> apache  9202 9485 9522
> harshit98   9263
> nehaljwani  9273
> juliusshufan9305
> katrinleinweber 9318
> HectorSVC   9369
> CodingCat   9389
> tornadomeet 9420
> pracheer9460
> hubenjm 9470
> chinakook   9492
> asmushetzel 9495
> lvaleriu9496
> opringle9512
> indhub  9519