Re: [INVITATION] 14th of May 2019 / Berlin MXNet Recurring User Group Meeting

[Wen-Yang Chu]

Hi  Per da Silva,

I would like to join this meeting. I would like to ask about some solution
of how to replace the depreciated "crop" layer properly.
I found many have the same issue and I do not find a proper solution. It
can be a real deal breaker for me despite I am really fond
of MXNET and use it in Philips for product development for more than 2
years. I am opening a startup and hope to continue using mxnet.
I am from Belgium by the way. See you today at 7PM

Best regards,

Wen-Yang

On Tue, May 14, 2019 at 1:52 PM Per da Silva  wrote:

> Dear MXNet community,
>
> I would like to invite you to the regular Apache MXNet (Incubating) User
> Group meeting on the 19th of March 2019 [1].
>
> As usually, the meeting will have remote VC, powered by Amazon Chime [2].
>
> Due to availability, **TODAY** It will be held from* 7pm-8pm (CEST) /
> 10am-11am (PST).* One hour later than usual.
>
> Join the meeting:
>
> https://chime.aws/2671929429
>
> Meeting ID: 2671929429
>
> Looking forward to meet you there.
>
> Best
> Per
>
> [1]
>
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28Incubating%29+
> User+Groups+recurring+meetings
> [2] https://chime.aws/
>

Re: [DISCUSS] Process to remove deprecated operators

[Wen-Yang Chu]

Hi,

I have raised an issue:

mx.nd.Crop does not support FP16 and decpreciated but no direct alternative
with central crop
I use this operator to implement Unet and I found other people too on the
Internent. It is very inconvenient to remove this specific operator
withoit clear alternative for me:

https://github.com/apache/incubator-mxnet/issues/13750

*Is it possible to review depreciated operators to make sure we have
equivalent functionality?*
Thanks

Wen-Yang

On Thu, Feb 28, 2019 at 2:07 PM Chaitanya Bapat 
wrote:

> This sounds good.
> Going further, if we can maintain a list of deprecated operators - we can
> create a "Good for first contribution" issue to improve log messaging of
> Deprecated operators.
> If it makes sense, I can go ahead and create that.
>
> Hope this helps.
>
> On Thu, 28 Feb 2019 at 01:54, Lin Yuan  wrote:
>
> > Agreed. When we deprecate an operator, we should add in the log message
> > something like "This operator X is deprecate and will be removed in the
> > next release. Please use operator Y instead."
> >
> > Lin
> >
> > On Wed, Feb 27, 2019 at 10:23 PM Junru Shao 
> > wrote:
> >
> > > Hi Lin,
> > >
> > > I would love to share some immature ideas about deprecating operators.
> > Not
> > > only adopting semantic versioning, but also should we provide enough
> > > informative error message for customers to understand how to replace
> > > deprecated operators with new ones.
> > >
> > > Thanks,
> > > Junru
> > >
> > > On Wed, Feb 27, 2019 at 9:30 PM Lin Yuan  wrote:
> > >
> > > > Sheng,
> > > >
> > > > Thanks for your quick response.
> > > > If that's the case, we will wait till 2.0 release to remove the
> > > deprecated
> > > > operators from code.
> > > >
> > > > Best,
> > > > Lin
> > > >
> > > > On Wed, Feb 27, 2019 at 9:06 PM Sheng Zha 
> wrote:
> > > >
> > > > > MXNet follows semantic versioning so we will be able to delete them
> > in
> > > > the
> > > > > next major release.
> > > > >
> > > > > -sz
> > > > >
> > > > > On Wed, Feb 27, 2019 at 8:53 PM Lin Yuan 
> > wrote:
> > > > >
> > > > > > Dear Community,
> > > > > >
> > > > > > In MXNet there are many legacy operators such as this
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> http://mxnet.incubator.apache.org/versions/master/api/python/symbol/symbol.html?highlight=convolution_v1#mxnet.symbol.Convolution_v1
> > > > > > >
> > > > > > that has been marked DEPRECATE for several releases. However,
> these
> > > > > > operators still exist in our code. This caused a few problems:
> > > > > >
> > > > > > 1) Make the codebase bloated and reduce readability
> > > > > > 2) Increase unnecessary maintanence effort
> > > > > > 3) Bug prone as some people will look up these legacy code as
> > example
> > > > > > 4) Cause confusion to end users and make documentation page
> lengthy
> > > > > >
> > > > > > I would like to propose the following process (if there is no
> > > existing
> > > > > one)
> > > > > > to remove deprecate operators from our code base.
> > > > > >
> > > > > > 1. Documnent the deprecate operators/environment variables in the
> > > > release
> > > > > > note as well as man pages.
> > > > > > 2. Limit the life cycle of deprecate operators/argument to two
> > minor
> > > > > > release. For example, if one operator is marked deprecate in 1.4
> > > > release,
> > > > > > it will be removed in 1.6 release.
> > > > > > 3. If there is some concern raised from customers during 1.4 and
> > 1.5
> > > > > > release, we can convert the deprecated operator back to current
> and
> > > it
> > > > > will
> > > > > > be treated as new operator.
> > > > > > 4. PRs that remove deprecate operators should contain [Cleanup]
> in
> > > > title.
> > > > > >
> > > > > > Any comment is appreciated.
> > > > > >
> > > > > > Lin
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> *Chaitanya Prakash Bapat*
> *+1 (973) 953-6299*
>
> [image: https://www.linkedin.com//in/chaibapat25]
> [image: https://www.facebook.com/chaibapat
> ]
> [image:
> https://twitter.com/ChaiBapchya] [image:
> https://www.linkedin.com//in/chaibapat25]
> 
>