Thanks Marco. I reviewed them and added many to the release note. See https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.1.0+Release+Notes
On Sat, Jan 27, 2018 at 12:20 AM, Marco de Abreu < marco.g.ab...@googlemail.com> wrote: > We might want to have a look at the following commits and add some of them > to the release notes: > https://github.com/apache/incubator-mxnet/commit/ > f960522fce032497ced6979ce7654f1f549d0434 > https://github.com/apache/incubator-mxnet/commit/ > c74cf1b3e3be8cfab7f92f646c9ac46ebe2ff6f8 > https://github.com/apache/incubator-mxnet/commit/ > 262c74c2c8228bfc60e0673bdf5ead0bf2e1973d > https://github.com/apache/incubator-mxnet/commit/ > 3ac5376cbe14faa120d382be62d32c9c49a0baa0 > https://github.com/apache/incubator-mxnet/commit/ > 5251b861693402a3e6394da990a5af183b6f7247 > https://github.com/apache/incubator-mxnet/commit/ > 4600070cd35bf4f1f3b93f4ce349c8e34e3610ae > https://github.com/apache/incubator-mxnet/commit/ > a80245d4d1a3005593456f743a34e396b774edbc > https://github.com/apache/incubator-mxnet/commit/ > 12cb0d20c7feb0ba1aa6fa6dd1208af8f2fb230c > https://github.com/apache/incubator-mxnet/commit/ > ddec3cc1ad4059016ca0a88e7f1b30bf48619d3a > https://github.com/apache/incubator-mxnet/commit/ > 09ed385e5059ffea2671e7d8a24a390cee7c1f8a > https://github.com/apache/incubator-mxnet/commit/ > c4a76da62fbc5e3e7272fd89294fba6b22868bba > https://github.com/apache/incubator-mxnet/commit/ > 167871a135308971c22cb8f6bdc2c8e7477fda6e > https://github.com/apache/incubator-mxnet/commit/ > b909769be11237e808c18e8afff55e7ab8877be9 > https://github.com/apache/incubator-mxnet/commit/ > d7da05b61adc9e4aba3e9995809b0d06965ae3bb > https://github.com/apache/incubator-mxnet/commit/ > fdc0766971ed95811d0db15ad0d878998192fce5 > > -Marco > > On Fri, Jan 26, 2018 at 10:28 PM, Haibin Lin <haibin.lin....@gmail.com> > wrote: > > > 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 <haibin.lin....@gmail.com> > > 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 > > > <http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/ > > incubator-mxnet/detail/PR-9560/1/pipeline/> > > > 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 > > > <http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/ > > incubator-mxnet/detail/PR-9522/1/pipeline/> > > > 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/9040> > > > - https://github.com/apache/incubator-mxnet/pull/9420 > > > <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 < > steffenroc...@gmail.com > > > > > > 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 <zhunanmcg...@gmail.com> > > >> 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 know that they can apply this release without > > making > > >> > >> major > > >> > >> > changes to their dependencies. It also helps set expectations > > >> around > > >> > >> the > > >> > >> > degree of regression testing you'd expect to do on a release > > >> > (typically > > >> > >> > patch releases would require less testing). For that reason if > > we > > >> > >> release > > >> > >> > as a patch release I think we could expect better adoption > rates > > in > > >> > the > > >> > >> > community and within large tech orgs. If we release as a minor > > >> > release > > >> > >> we > > >> > >> > should expect that many customers may take a long time to > update, > > >> and > > >> > >> as a > > >> > >> > community we will be forced to provide support for bugs which > > have > > >> > >> already > > >> > >> > been fixed. > > >> > >> > > > >> > >> > +1 (non-binding) In terms of branching I'd agree that we should > > >> apply > > >> > >> most > > >> > >> > of the fixes to the previous release branch and build from > there. > > >> > >> Happy to > > >> > >> > help with this if needed. > > >> > >> > > > >> > >> > On Thu, Jan 25, 2018 at 6:19 AM, Nan Zhu < > zhunanmcg...@gmail.com > > > > > >> > >> wrote: > > >> > >> > > > >> > >> > > +1 and suggest consolidating all maintenance releases under > the > > >> same > > >> > >> > > major.minor version into a single branch > > >> > >> > > > > >> > >> > > On Wed, Jan 24, 2018 at 9:06 PM, Meghna Baijal < > > >> > >> > meghnabaijal2...@gmail.com > > >> > >> > > > > > >> > >> > > wrote: > > >> > >> > > > > >> > >> > > > 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" < > > >> > >> > marco.g.ab...@googlemail.com> > > >> > >> > > > 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" < > > >> > >> zhash...@amazon.com > > >> > >> > >: > > >> > >> > > > > > > >> > >> > > > > > 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 < > > >> > >> > cjolivie...@gmail.com> > > >> > >> > > > > > 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 < > > >> > >> > > > haibin.lin....@gmail.com> > > >> > >> > > > > > 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 > > >> > >> > > > > > >>>> tests due to non-deterministic behavior (see > issues > > >> > >> > > > > > >>>> <https://github.com/apache/inc > > >> ubator-mxnet/labels/Flaky > > >> > >). > > >> > >> > I'm > > >> > >> > > > > > calling > > >> > >> > > > > > >> on > > >> > >> > > > > > >>>> all contributors to help to resolve the > > >> non-deterministic > > >> > >> > > > behavior, > > >> > >> > > > > so > > >> > >> > > > > > >> we > > >> > >> > > > > > >>>> can improve our test coverage. As we discussed > > >> offline, > > >> > >> lets > > >> > >> > > tests > > >> > >> > > > > > >>>> manually > > >> > >> > > > > > >>>> short term, document the known issue in the > release > > >> notes > > >> > >> and > > >> > >> > > > > > prioritize > > >> > >> > > > > > >>>> efforts post 1.0.1 release. > > >> > >> > > > > > >>>> > > >> > >> > > > > > >>>> Regards, > > >> > >> > > > > > >>>> Steffen > > >> > >> > > > > > >>>> > > >> > >> > > > > > >>>>> On Wed, Jan 17, 2018 at 5:05 PM Sheng Zha < > > >> > >> > zhash...@apache.org > > >> > >> > > > > > >> > >> > > > > > wrote: > > >> > >> > > > > > >>>>> > > >> > >> > > > > > >>>>> Hi Haibin, > > >> > >> > > > > > >>>>> > > >> > >> > > > > > >>>>> Thanks for leading this. I suggest that we hold > > onto > > >> > this > > >> > >> > > release > > >> > >> > > > > > >> until > > >> > >> > > > > > >>>> we > > >> > >> > > > > > >>>>> have clarity on the following items. > > >> > >> > > > > > >>>>> > > >> > >> > > > > > >>>>> 1. branch usage and versioning > > >> > >> > > > > > >>>>> Given that we are past 1.0 and we're changing > APIs, > > >> I'd > > >> > >> like > > >> > >> > to > > >> > >> > > > > > >> suggest > > >> > >> > > > > > >>>>> that we first agree on how > > >> > >> > > > > > >>>>> versioning works in mxnet. If we follow semantic > > >> > >> versioning, > > >> > >> > it > > >> > >> > > > > would > > >> > >> > > > > > >>>>> suggest that features like > > >> > >> > > > > > >>>>> MKL-DNN should go at least into 1.1 (minor > version > > >> > change) > > >> > >> > > > instead > > >> > >> > > > > of > > >> > >> > > > > > >>>>> 1.0.1 (patch release). > > >> > >> > > > > > >>>>> Also, assuming that new release will come from a > > new > > >> > >> forked > > >> > >> > > > > branch, I > > >> > >> > > > > > >>>>> suggest that we clarify on how to > > >> > >> > > > > > >>>>> name the branches too. > > >> > >> > > > > > >>>>> You can find relevant thread at > > >> > >> > > > > > >>>>> https://lists.apache.org/threa > > >> > >> d.html/c52f8353f63c1e63b2646ec > > >> > >> > > > > > >>>> 3b08d9a8180a1381787d777b41b8ac69f@% > > >> > 3Cdev.mxnet.apache.org > > >> > >> %3E > > >> > >> > > > > > >>>>> > > >> > >> > > > > > >>>>> 2. disabled tests > > >> > >> > > > > > >>>>> For the purpose of stabilizing test automation > > >> system, > > >> > >> many > > >> > >> > > tests > > >> > >> > > > > > were > > >> > >> > > > > > >>>>> disabled. In order to avoid > > >> > >> > > > > > >>>>> releasing untested features, we should mitigate > the > > >> > >> situation > > >> > >> > > of > > >> > >> > > > > > >> having > > >> > >> > > > > > >>>>> disabled tests. > > >> > >> > > > > > >>>>> That means we can fix the tests before the > release, > > >> or > > >> > >> remove > > >> > >> > > the > > >> > >> > > > > > >>>>> corresponding feature from release > > >> > >> > > > > > >>>>> (might be hard to do, e.g. for optimizer). > > >> Otherwise, we > > >> > >> must > > >> > >> > > > > > >>>> collectively > > >> > >> > > > > > >>>>> decide that a feature is > > >> > >> > > > > > >>>>> OK to release without tests. > > >> > >> > > > > > >>>>> The thread on this topic can be found at > > >> > >> > > > > > >>>>> https://lists.apache.org/threa > > >> > >> d.html/addab1937bfcf09b5dfa15c > > >> > >> > > > > > >>>> 1149ddcebd084f1c4bf4e10a73770fb35@% > > >> > 3Cdev.mxnet.apache.org > > >> > >> %3E > > >> > >> > > > > > >>>>> > > >> > >> > > > > > >>>>> We can proceed on the release with more > confidence > > >> once > > >> > we > > >> > >> > have > > >> > >> > > > > > >> clarity. > > >> > >> > > > > > >>>>> > > >> > >> > > > > > >>>>> Best regards, > > >> > >> > > > > > >>>>> -sz > > >> > >> > > > > > >>>>> > > >> > >> > > > > > >>>>>> On 2018-01-10 15:33, Haibin Lin < > > >> > >> haibin.lin....@gmail.com> > > >> > >> > > > wrote: > > >> > >> > > > > > >>>>>> I am starting the process to prepare for MXNET > > 1.0.1 > > >> > >> > release. > > >> > >> > > I > > >> > >> > > > > have > > >> > >> > > > > > >>>>>> drafted release notes > > >> > >> > > > > > >>>>>> (* > > >> > >> > > > > > >>>>> > > >> > https://cwiki.apache.org/confluence/display/MXNET/Apache+ > > >> > >> > > > > > >>>> MXNet+%28incubating%29+1.0.1+Release+Notes > > >> > >> > > > > > >>>>>> < > > >> > >> > > > > > >>>>> > > >> > https://cwiki.apache.org/confluence/display/MXNET/Apache+ > > >> > >> > > > > > >>>> MXNet+%28incubating%29+1.0.1+Release+Notes > > >> > >> > > > > > >>>>>> *) > > >> > >> > > > > > >>>>>> to cover the tasks under this release. > > >> > >> > > > > > >>>>>> > > >> > >> > > > > > >>>>>> A release candidate will be cut on Monday 22nd > > Jan, > > >> > 2018 > > >> > >> and > > >> > >> > > > > voting > > >> > >> > > > > > >>>> will > > >> > >> > > > > > >>>>>> commence from then till Thursday 25th Jan, 2018. > > If > > >> you > > >> > >> have > > >> > >> > > any > > >> > >> > > > > > >>>>> additional > > >> > >> > > > > > >>>>>> features in progress and would like to include > it > > in > > >> > this > > >> > >> > > > release, > > >> > >> > > > > > >>>> please > > >> > >> > > > > > >>>>>> assure they have been merged by Thursday 18th > Jan, > > >> 2018 > > >> > >> with > > >> > >> > > > > comment > > >> > >> > > > > > >>>> so I > > >> > >> > > > > > >>>>>> may update the release notes. > > >> > >> > > > > > >>>>>> > > >> > >> > > > > > >>>>>> Feel free to add any other comments/suggestions. > > >> > >> > > > > > >>>>>> > > >> > >> > > > > > >>>>>> Thanks, > > >> > >> > > > > > >>>>>> Haibin > > >> > >> > > > > > >>>>>> > > >> > >> > > > > > >>>>> > > >> > >> > > > > > >>>> > > >> > >> > > > > > >>> > > >> > >> > > > > > >>> > > >> > >> > > > > > >> > > >> > >> > > > > > > > >> > >> > > > > > > >> > >> > > > > > >> > >> > > > > >> > >> > > > >> > >> > > >> > > > > >> > > > > >> > > > >> > > > > > > > > >
