mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Haibin Lin <haibin.lin....@gmail.com>
Subject Re: Release plan - MXNET 1.0.1
Date Sun, 28 Jan 2018 01:03:50 GMT
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.abreu@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.aws@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.aws@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 <
> steffenrochel@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.sunderland@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.sunderland@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 <zhunanmcgill@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.sunderland@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 <
> zhunanmcgill@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
<
> > >> > >> > meghnabaijal2017@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.abreu@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" <
> > >> > >> zhasheng@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 <
> > >> > >> > cjolivier01@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.aws@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.aws@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 <
> > >> > >> > > > > > steffenrochel@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 <
> > >> > >> > zhasheng@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.aws@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
> > >> > >> > > > > > >>>>>>
> > >> > >> > > > > > >>>>>
> > >> > >> > > > > > >>>>
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>
> > >> > >> > > > > >
> > >> > >> > > > >
> > >> > >> > > >
> > >> > >> > >
> > >> > >> >
> > >> > >>
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message