Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 JVM Language development (#17783)

[Carin Meier]

@saudet @szha - I think we be a good path forward (from the Clojure perspective)

-- 
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17783#issuecomment-663085890

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

[Carin Meier]

Zach,

If you are willing and able to do that on behalf of Amazon, that would be
great.

-Carin

On Fri, May 29, 2020 at 8:35 PM Zach Kimberg 
wrote:

> If we replace the official CPU build, won't there still be new dependencies
> so it is not even guaranteed to work depending on whether the user has the
> dependencies (e.g. libgfortran) installed? I think there is also a
> performance degradation if we remove mkl.
>
> But, we could still have a third-party build. I can try to redo the builds
> and release it on behalf of Amazon. Those builds can contain the full
> dependencies and supported environments (CPU, GPU, OSX) and are not
> restricted to Apache's license policies. Users will only have to update
> their dependency group IDs and they will get the same functionality as they
> have now.
>
> As Apache, we will only officially support JVM by building from source.
> Then, we just mention where to find the Amazon convenience builds while
> clarifying that they are not official Apache builds.
>
> On Fri, May 29, 2020 at 10:44 AM Carin Meier  wrote:
>
> > Thanks. I understand now. If all the current jars are not compliant, then
> > they should be removed.
> > I also don't like the idea of "replacing" a jar on maven with another
> jar.
> > It sounds like we can consider publishing cpu jars only going forward
> for a
> > new release.
> >
> > - Carin
> >
> > On Fri, May 29, 2020 at 1:32 PM Lausen, Leonard
>  > >
> > wrote:
> >
> > > On Fri, 2020-05-29 at 12:15 -0400, Carin Meier wrote:
> > > >
> > > > Going forward - we with future releases, we can have all users build
> > > their
> > > > own packages, just for the existing ones that are compliant on maven.
> > > >
> > > > On Fri, May 29, 2020 at 12:14 PM Carin Meier 
> > > wrote:
> > > >
> > > > > Leonard,
> > > > >
> > > > > Is this #2 Option still on the table?
> > > > >
> > > > >  2) Ask the Infra team to delete all MXNet GPU releases on
> > > > > > repository.apache.org and provide replacement releases without
> > > > > libgfortran.so
> > > > > > and other potentially Category-X files (I found libmkl_ml.so in
> one
> > > of
> > > > > the
> > > > > > JARs..)
> > > > >
> > > > > It seems like it would be a better solution than deleting ALL of
> > them,
> > > if
> > > > > the CPU ones are still valid and adhere to licensing.
> > > > > At least, we would break fewer users.
> > > > >
> > > > > - Carin
> > >
> > > Yes, this is a valid option. Just to clarify, the existing CPU releases
> > > don't
> > > adhere to the ASF policy. But MXNet project could create new, compliant
> > CPU
> > > releases and upload them to repository.apache.org. Finding a way to do
> > > this for
> > > the existing 1.x releases would also establish a path forward to
> continue
> > > creating such JARs for upcoming releases.
> > >
> >
>

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

[Carin Meier]

Thanks. I understand now. If all the current jars are not compliant, then
they should be removed.
I also don't like the idea of "replacing" a jar on maven with another jar.
It sounds like we can consider publishing cpu jars only going forward for a
new release.

- Carin

On Fri, May 29, 2020 at 1:32 PM Lausen, Leonard 
wrote:

> On Fri, 2020-05-29 at 12:15 -0400, Carin Meier wrote:
> >
> > Going forward - we with future releases, we can have all users build
> their
> > own packages, just for the existing ones that are compliant on maven.
> >
> > On Fri, May 29, 2020 at 12:14 PM Carin Meier 
> wrote:
> >
> > > Leonard,
> > >
> > > Is this #2 Option still on the table?
> > >
> > >  2) Ask the Infra team to delete all MXNet GPU releases on
> > > > repository.apache.org and provide replacement releases without
> > > libgfortran.so
> > > > and other potentially Category-X files (I found libmkl_ml.so in one
> of
> > > the
> > > > JARs..)
> > >
> > > It seems like it would be a better solution than deleting ALL of them,
> if
> > > the CPU ones are still valid and adhere to licensing.
> > > At least, we would break fewer users.
> > >
> > > - Carin
>
> Yes, this is a valid option. Just to clarify, the existing CPU releases
> don't
> adhere to the ASF policy. But MXNet project could create new, compliant CPU
> releases and upload them to repository.apache.org. Finding a way to do
> this for
> the existing 1.x releases would also establish a path forward to continue
> creating such JARs for upcoming releases.
>

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

[Carin Meier]

Going forward - we with future releases, we can have all users build their
own packages, just for the existing ones that are compliant on maven.

On Fri, May 29, 2020 at 12:14 PM Carin Meier  wrote:

> Leonard,
>
> Is this #2 Option still on the table?
>
>  2) Ask the Infra team to delete all MXNet GPU releases on
> > repository.apache.org and provide replacement releases without
> libgfortran.so
> > and other potentially Category-X files (I found libmkl_ml.so in one of
> the
> > JARs..)
>
> It seems like it would be a better solution than deleting ALL of them, if
> the CPU ones are still valid and adhere to licensing.
> At least, we would break fewer users.
>
> - Carin
>
> On Wed, May 27, 2020 at 2:18 PM Lausen, Leonard 
> wrote:
>
>> Ok, so let's restart the lazy consensus on the removal of the Maven
>> artifacts.
>> As there were concerns that this is to rushed, let's make it a 168 hour
>> (7 day)
>> lazy consenus. I'm happy to cancel it again if anyone has a better idea
>> and
>> ressources to implement it.
>>
>> Just to clarify, similar to the Pypi packages, non-ASF third-parties
>> (individuals or companies) are free to publish Maven packages on some
>> non-ASF
>> infrastructure, as long as they don't infringe trademarks of the ASF.
>> Sheng is
>> doing that on Pypi.
>>
>> Best regards
>> Leonard
>>
>> On Wed, 2020-05-27 at 14:54 +0200, Marco de Abreu wrote:
>> > Thanks for your input Carin.
>> >
>> > In that case, I'll take back my -1 and feel free to proceed.
>> >
>> > -Marco
>> >
>> > Carin Meier  schrieb am Mi., 27. Mai 2020, 14:53:
>> >
>> > > Leonard,
>> > >
>> > > Thank you for putting the pull request together. Unfortunately, I
>> don't
>> > > have any bandwidth to assist with any JVM activities right now, so I
>> will
>> > > defer to those that are have time and are willing to put in the dev
>> effort.
>> > >
>> > > However, I will give my opinion that having a jar load and then fail
>> with
>> > > an error message is worse than not having the artifact on Maven at
>> all.
>> > > If it is going to fail, it should fail fast before it breaks things
>> later
>> > > in the chain.
>> > >
>> > > Removing the artifact from maven is awful and it will break users.
>> This is
>> > > undoubtably a situation that none of us want to be in, but I
>> understand
>> > > from a legal standpoint that we have no other option. The best I can
>> > > suggest is to open a preemptive issue on Github, so that users can
>> > > remediate the problem by building the package themselves.
>> > >
>> > > Let's work together to get though this the best we can and move
>> forward
>> > > towards graduation.
>> > >
>> > > Best,
>> > > Carin
>> > >
>> > > On Tue, May 26, 2020 at 9:46 PM Lausen, Leonard
>> > > > wrote:
>> > >
>> > > > Hi Marco,
>> > > >
>> > > > thank you for explaining your reasoning. Thus let's cancel the lazy
>> > > > consensus.
>> > > >
>> > > > I think we're all aware of the impact of this problem you mention
>> and I
>> > > > too am
>> > > > concerned about it. But, please note that this discussion has been
>> > > ongoing
>> > > > for
>> > > > 14 days and there has been no proposal for mitigating the problems.
>> > > Maybe 2
>> > > > weeks to you is "driven out of necessity on full speed". From my
>> > > > perspective 14
>> > > > days is a reasonable timeframe. The issues are severe and certainly
>> block
>> > > > any
>> > > > progress on the graduation of MXNet. So this issue shouldn't be
>> taken
>> > > > lightly.
>> > > >
>> > > > In either case, thank you for your belated addition of a new
>> proposal:
>> > > > "replace
>> > > > the published package with a stub with the same signatures (so it
>> loads
>> > > > properly), but throwing a fatal error message on load, linking to
>> our
>> > > > documentation and explaining the situation"
>> > > >
>> > > > It's certainly better than deleting the packages, and less effort
>> than
>> > > 

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

[Carin Meier]

Leonard,

Is this #2 Option still on the table?

 2) Ask the Infra team to delete all MXNet GPU releases on
> repository.apache.org and provide replacement releases without
libgfortran.so
> and other potentially Category-X files (I found libmkl_ml.so in one of the
> JARs..)

It seems like it would be a better solution than deleting ALL of them, if
the CPU ones are still valid and adhere to licensing.
At least, we would break fewer users.

- Carin

On Wed, May 27, 2020 at 2:18 PM Lausen, Leonard 
wrote:

> Ok, so let's restart the lazy consensus on the removal of the Maven
> artifacts.
> As there were concerns that this is to rushed, let's make it a 168 hour (7
> day)
> lazy consenus. I'm happy to cancel it again if anyone has a better idea and
> ressources to implement it.
>
> Just to clarify, similar to the Pypi packages, non-ASF third-parties
> (individuals or companies) are free to publish Maven packages on some
> non-ASF
> infrastructure, as long as they don't infringe trademarks of the ASF.
> Sheng is
> doing that on Pypi.
>
> Best regards
> Leonard
>
> On Wed, 2020-05-27 at 14:54 +0200, Marco de Abreu wrote:
> > Thanks for your input Carin.
> >
> > In that case, I'll take back my -1 and feel free to proceed.
> >
> > -Marco
> >
> > Carin Meier  schrieb am Mi., 27. Mai 2020, 14:53:
> >
> > > Leonard,
> > >
> > > Thank you for putting the pull request together. Unfortunately, I don't
> > > have any bandwidth to assist with any JVM activities right now, so I
> will
> > > defer to those that are have time and are willing to put in the dev
> effort.
> > >
> > > However, I will give my opinion that having a jar load and then fail
> with
> > > an error message is worse than not having the artifact on Maven at all.
> > > If it is going to fail, it should fail fast before it breaks things
> later
> > > in the chain.
> > >
> > > Removing the artifact from maven is awful and it will break users.
> This is
> > > undoubtably a situation that none of us want to be in, but I understand
> > > from a legal standpoint that we have no other option. The best I can
> > > suggest is to open a preemptive issue on Github, so that users can
> > > remediate the problem by building the package themselves.
> > >
> > > Let's work together to get though this the best we can and move forward
> > > towards graduation.
> > >
> > > Best,
> > > Carin
> > >
> > > On Tue, May 26, 2020 at 9:46 PM Lausen, Leonard
>  > > wrote:
> > >
> > > > Hi Marco,
> > > >
> > > > thank you for explaining your reasoning. Thus let's cancel the lazy
> > > > consensus.
> > > >
> > > > I think we're all aware of the impact of this problem you mention
> and I
> > > > too am
> > > > concerned about it. But, please note that this discussion has been
> > > ongoing
> > > > for
> > > > 14 days and there has been no proposal for mitigating the problems.
> > > Maybe 2
> > > > weeks to you is "driven out of necessity on full speed". From my
> > > > perspective 14
> > > > days is a reasonable timeframe. The issues are severe and certainly
> block
> > > > any
> > > > progress on the graduation of MXNet. So this issue shouldn't be taken
> > > > lightly.
> > > >
> > > > In either case, thank you for your belated addition of a new
> proposal:
> > > > "replace
> > > > the published package with a stub with the same signatures (so it
> loads
> > > > properly), but throwing a fatal error message on load, linking to our
> > > > documentation and explaining the situation"
> > > >
> > > > It's certainly better than deleting the packages, and less effort
> than
> > > > re-doing
> > > > all the releases in an ASF-compliant manner. Let's wait another few
> days
> > > > if any
> > > > MXNet committers, perhaps one that is already familiar with the JVM
> > > > packaging
> > > > and ecosystem, will volunteer to implement this.
> > > >
> > > > Best regards
> > > > Leonard
> > > >
> > > >
> > > > On Wed, 2020-05-27 at 02:36 +0200, Marco de Abreu wrote:
> > > > > Hi,
> > > > >
> > > > > I'm upholding my -1 until a clear path to communicate and handle
> the
> > > > change
> > > > >

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

[Carin Meier]

ously failed to follow the ASF release
> policies
> > > for
> > > convenience binaries (the policies were only followed and discussed for
> > > source
> > > releases).
> > >
> > > If you have a different proposal to the ones discussed during the last
> 14
> > > days,
> > > please present it. If you would like to volunteer re-doing all the old
> > > convenience releases in an ASF compliant manner, that would also be
> great.
> > >
> > > Please clarify this if your "-1" is intended to start a procedural vote
> > > according to [1] in which the majority of votes determines the
> outcome. In
> > > that
> > > case I suggest to change the email title to begin with [VOTE].
> Otherwise
> > > I'll
> > > assume the lazy consensus still remains.
> > >
> > > [1]: https://www.apache.org/foundation/voting.html
> > >
> > > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
> > >
> > > > Do we offer any replacement for those deletions or will be break
> stuff
> > > > then?
> > > >
> > > > If we break anything, I'd -1 until we found a way moving forward to
> > > ensure
> > > > uninterrupted service.
> > > >
> > > > On Tue, May 26, 2020 at 7:51 PM Carin Meier 
> > > wrote:
> > > > > Does anyone have any bandwidth to update installation
> documentation on
> > > the
> > > > > website, so it doesn't refer them to install it from maven?
> > > > >
> > > > > Here are the links to the gpu instructions for Scala, Java, and
> > > Clojure.
> > > > > The cpu ones will also need to be updated if also removed.
> > > > >
> > > > >
> > >
> https://mxnet.apache.org/get_started?platform=linux=scala=gpu;
> ;
> > > ;
> > > > >
> > >
> https://mxnet.apache.org/get_started?platform=linux=java=gpu;
> ;
> > > ;
> > > > >
> > >
> https://mxnet.apache.org/get_started?platform=linux=clojure=gpu;
> ;
> > > ;
> > > > > Thanks,
> > > > > Carin
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
> > >  > > > > wrote:
> > > > >
> > > > > > On Fri, 2020-05-08 at 20:49 +, Lausen, Leonard wrote:
> > > > > > > I see the following two potential remedies:
> > > > > > >
> > > > > > > 1) Ask the Infra team to delete all MXNet releases on
> > > > > > repository.apache.org
> > > > > > > 2) Ask the Infra team to delete all MXNet GPU releases on
> > > > > > > repository.apache.org and provide replacement releases without
> > > > > > libgfortran.so
> > > > > > > and other potentially Category-X files (I found libmkl_ml.so in
> > > one of
> > > > > > the
> > > > > > > JARs..)
> > > > > > >
> > > > > > > If no-one steps up to do 2) or no-one suggests a better
> option, I
> > > > > > recommend we
> > > > > > > go for option 1). Let's start discussing the options. Once
> > > discussion
> > > > > has
> > > > > > > settled, I'll initiate a lazy consensus or vote session.
> > > > > >
> > > > > > As the discussion appears to have settled and there appears to
> be no
> > > > > > progress on
> > > > > > providing replacement JARs without Category-X files for old
> > > releases, I
> > > > > > would
> > > > > > like to start 72 hour lazy consensus on "Ask the Infra team to
> > > delete all
> > > > > > MXNet
> > > > > > releases on repository.apache.org".
> > > > > >
> > > > > > Best regards
> > > > > > Leonard
> > > > > >
>

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

[Carin Meier]

Does anyone have any bandwidth to update installation documentation on the
website, so it doesn't refer them to install it from maven?

Here are the links to the gpu instructions for Scala, Java, and Clojure.
The cpu ones will also need to be updated if also removed.
https://mxnet.apache.org/get_started?platform=linux=scala=gpu;
https://mxnet.apache.org/get_started?platform=linux=java=gpu;
https://mxnet.apache.org/get_started?platform=linux=clojure=gpu;

Thanks,
Carin




On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard 
wrote:

> On Fri, 2020-05-08 at 20:49 +, Lausen, Leonard wrote:
> > I see the following two potential remedies:
> >
> > 1) Ask the Infra team to delete all MXNet releases on
> repository.apache.org
> >
> > 2) Ask the Infra team to delete all MXNet GPU releases on
> > repository.apache.org and provide replacement releases without
> libgfortran.so
> > and other potentially Category-X files (I found libmkl_ml.so in one of
> the
> > JARs..)
> >
> > If no-one steps up to do 2) or no-one suggests a better option, I
> recommend we
> > go for option 1). Let's start discussing the options. Once discussion has
> > settled, I'll initiate a lazy consensus or vote session.
>
> As the discussion appears to have settled and there appears to be no
> progress on
> providing replacement JARs without Category-X files for old releases, I
> would
> like to start 72 hour lazy consensus on "Ask the Infra team to delete all
> MXNet
> releases on repository.apache.org".
>
> Best regards
> Leonard
>

Re: Severe legal issues with releases on repository.apache.org

[Carin Meier]

Does removing the jars from both of these solutions also remove them from
maven central?
>
>
> 1) Ask the Infra team to delete all MXNet releases on
> repository.apache.org
> 2) Ask the Infra team to delete all MXNet GPU releases on
> repository.apache.org
> and provide replacement releases without libgfortran.so and other
> potentially
> Category-X files (I found libmkl_ml.so in one of the JARs..)


If so, either of these options has potential to cause major disruption for
users that depend on using them in production. If either of these actions
are deemed necessary, we should strive to provide communication to end
users and a solution for a process of how to replace them.


- Carin

On Mon, May 11, 2020 at 1:44 PM Lausen, Leonard 
wrote:

> On Sun, May 10, 2020 at 8:06 AM Markus Weimer  wrote:
> > On Sat, May 9, 2020 at 10:50 PM Tianqi Chen 
> wrote:
> > >
> > > Seems the conclusion so far is only release source through apache and
> > > release the binary builds as third party(as a different community, a
> > > company or individual)
> >
> > Yes, that is the precedent established in multiple projects. I think
> > it might still be worthwhile to pursue an exception from nvidia,
> > though. Do we have any nvidia employees on the list that can inquire
> > about that?
>
> Triston helped to establish contact with the Nvidia Legal team and we're
> currently waiting for a response on their interpretation of the EULA as
> well as
> the possibility of an exception. It would be great to have an "internal
> lobby"
> for granting an GCC Runtime Library Exception style exception for nvcc in
> general, or at least ASF in particular.
>
> On Sun, 2020-05-10 at 08:52 -0700, Tianqi Chen wrote:
> > I agree, In the meanwhile. @Leonard I think we should ask
> trademark@apache
> > whether they would approve the use of
> >
> > repo names: mxnet-cu80 mxnet-cu10 etc, given that
> > - they are distributed by individual contributors(as individuals and not
> as
> > ASF PPMC members),
> > - marked as thirdparty binary
> > - Build from the original ASF source with no modifications, while with an
> > "optional build config" that enables CUDA acceleration support, which
> > abides the rules in
> https://www.apache.org/foundation/marks/downstream.html
>
> Currently https://issues.apache.org/jira/browse/LEGAL-515 asks similar
> questions
> to the Legal Team, but there is no conclusion yet. One open question in
> LEGAL-
> 515 is if the CD system managed in the project's source code at
> https://github.com/apache/incubator-mxnet/tree/master/cd can be seen as
> releasing third-party binaries given that it doesn't run on Apache
> infrastructure. In the "worst case" the CD in the ASF repo must be
> restricted to
> build ASF-compliant binaries and third-parties need to manage their own CD
> outside the Apache repo.
>
> Once we have clarity on that, let's continue clarifying with the
> trademarks@
> team.
>
> Best regards
> Leonard
>

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 JVM Language development (#17783)

[Carin Meier]

For the Clojure package. It is a lot easier to interop with Java than with 
Scala - so if the the base is Java that  every thing is using - it will be 
better for Clojure.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17783#issuecomment-596779618

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 JVM Language development (#17783)

[Carin Meier]

@lanking520 thanks for the clarification above. A further question - How do 
envision a current Scala MXNet user migrate their code? Is it going to be 
mostly reusable or is it going to be a current rewrite for them?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17783#issuecomment-596714532

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Carin Meier]

Good question. I don't know. There wasn't a new release then. 路‍♀ 

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595885111

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Carin Meier]

Thanks @zachgk  - I took a couple of screenshots so I could share here

Here is the Scala package
![scala-mxnet](https://user-images.githubusercontent.com/340299/76096507-3b206a00-5f94-11ea-839a-168fb923a59d.png)

and here is the Clojure package
![clojure-mxnet-downloads](https://user-images.githubusercontent.com/340299/76096528-41164b00-5f94-11ea-8313-5bfbc97ff689.png)

There are far more Scala downloads that Clojure.

@lanking520 and other Scala package maintainers. I thank you for all the work 
that you've done on the Scala package so far. I will support whatever decision 
makes most sense for the Scala package makes for the JVM MNNet users for 2.0.

Let's just make a plan and coordinate whatever that is so that the current 
users have the most information to plan accordingly.



-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595818419

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Carin Meier]

Is there anyway to get the stats on downloads of the maven central 
scala/clojure jars to see how much current use there is? If the numbers are 
high or low and what trend is can help shape the decision

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595511949

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Carin Meier]

Further thinking this through - since the Scala language binding currently 
provides the base for both Java and Clojure, I would be nice to know what the 
future plans for the Scala language binding is. Whether or not that path is 
supported will determine the other JVM langs.

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595256200

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Carin Meier]

If I understand this correctly, since the Scala, Java, and Clojure bindings use 
symbol and ndarray exclusively, this will also mean that they will be 
effectively deprecated as well.

This is fine if what the community decides upon, but it should be called out 
explicitly.

cc @lanking520 @nswamy @kedarbellare 

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595245038

Re: new website, docs code freeze

[Carin Meier]

Nice!!! Congrats everyone!

On Fri, Sep 20, 2019 at 10:28 AM Aaron Markham 
wrote:

> Alrighty! The new site is launched. You might need to clear your cache.
>
> Cheers,
> Aaron
>
> On Thu, Sep 19, 2019 at 3:33 PM Aaron Markham 
> wrote:
> >
> > Thanks everyone. The PRs passed CI, but please continue holding off on
> > docs and CI edits. Unless there are any objections, I'd like to launch
> > the new website today.
> >
> > On Wed, Sep 18, 2019 at 7:46 AM Aaron Markham 
> wrote:
> > >
> > > Hi everyone,
> > > The last two PRs [1][2] for the new website and docs have passed CI
> > > (finally). Please do not make changes to /docs or /ci until we get
> > > these approved and merged. Every time there's a merge conflict it has
> > > set us back a day or two while shepherding the PRs through CI again.
> > > Unless there are catastrophic issues discovered in a review, I
> > > recommend that we hold any patches or updates to the PRs to follow-up
> > > PRs.
> > >
> > > There are four steps to launch:
> > > 1. Once the PRs are approved, the plan is to merge 15885 to delete the
> > > old content first.
> > > 2. Then immediately merge 15883 to add in the new CI flows and updates
> > > to the content Thomas and I have already had merged in 15884 [3].
> > > 3. I will change the website validation Jenkins pipeline to point to
> > > the new pipeline.
> > > 4. I will change the website publishing Jenkins pipeline to point to
> > > its new pipeline as well. Once triggered, the old site will be
> > > replaced with the new one.
> > >
> > > Post launch we'll need to update the DNS for beta.mxnet.io to point to
> > > production, and there will likely be some redirect/.htaccess updates
> > > needed next week to assist with any deep linking and 404 issues that
> > > pop up.
> > >
> > > Cheers,
> > > Aaron
> > >
> > > [1] https://github.com/apache/incubator-mxnet/pull/15885
> > > [2] https://github.com/apache/incubator-mxnet/pull/15883
> > > [3] https://github.com/apache/incubator-mxnet/pull/15884
>

Re: [VOTE] Release Apache MXNet (incubating) 1.5.1.rc0

[Carin Meier]

+1 built and tested the Clojure package

On Fri, Sep 20, 2019 at 12:08 AM Srivastava, Rohit Kumar <
srivastava@buckeyemail.osu.edu> wrote:

> +1
> build mxnet from source with large tensor support. Ran tests only for
> large array. All passed !
>
> On 9/19/19, 2:58 PM, "Lai Wei"  wrote:
>
> +1
>
> build from source on GPU and tested with gluon estimator and latest
> keras-mxnet.
>
>
> Best Regards
>
> Lai
>
>
> On Thu, Sep 19, 2019 at 1:02 PM sandeep krishnamurthy <
> sandeep.krishn...@gmail.com> wrote:
>
> > Thank you Tao for leading this and all the community members for
> helping in
> > this release.
> >
> >
> > +1
> >
> >
> > -[Y] Are release files in correct location?
> >
> > -[Y] Do release files have the word incubating in their name?
> >
> > -[Y] Are the digital signature and hashes correct?
> >
> > -[Y] Does DISCLAIMER file exist?
> >
> > -[Y] Do LICENSE and NOTICE files exists?
> >
> > -[Y] Is the LICENSE and NOTICE text correct?
> >
> > -[Y] Is the NOTICE year correct?
> >
> > -[Y] Un-included software dependencies are not mentioned in LICENSE
> or
> > NOTICE?
> >
> > -[Y] License information is not mentioned in NOTICE?
> >
> > Is there any 3rd party code contained inside the release? If so:
> >
> > -[N] Does the software have a compatible license?
> >
> > -[Y] Are all software licenses mentioned in LICENSE?
> >
> > -[Y] Is the full text of the licenses (or pointers to it) in LICENSE?
> >
> > Is any of this code Apache licensed? Do they have NOTICE files? If
> so:
> >
> > -[Y] Have relevant parts of those NOTICE files been added to this
> NOTICE
> >
> > file?
> >
> > -[Y] Do all source files have ASF headers?
> >
> > -[Y] Do the contents of the release match with what's tagged in
> version
> > control?
> >
> > -[N] Are there any unexpected binary files in the release?
> >
> > -[Y] Can you compile from source? Are the instruction clear?
> >
> >
> > Except the license issue mentioned in this Github issue -
> > https://github.com/apache/incubator-mxnet/issues/15542
> >
> >
> > I was able to build from source on GPU(p3.2x EC2 instance) and run
> > opperf-operator
> > benchmark utilit
> > <
> https://github.com/apache/incubator-mxnet/tree/master/benchmark/opperf>y
> > successfully
> > with no regression compared to v1.5.0.
> >
> >
> >
> >
> > On Thu, Sep 19, 2019 at 11:51 AM Anirudh Subramanian <
> > anirudh2...@gmail.com>
> > wrote:
> >
> > > +1
> > >
> > > Build from source with cmake and ran unittest for gluon and amp.
> > >
> > > Noticed that test_sync_batchnorm fails on p3.8xlarge (hidden by
> the CI
> > > because passes on machines with 1 or 2 gpus).
> > > I have opened an issue for the same
> > > https://github.com/apache/incubator-mxnet/issues/16214 though I
> think
> > its
> > > not a blocker for this release.
> > >
> > > Anirudh
> > >
> > > On Thu, Sep 19, 2019 at 11:28 AM Chaitanya Bapat <
> chai.ba...@gmail.com>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > Correctly built for GPU, CPU on Ubuntu 14.01 (10.1 Cuda for GPU)
> > > > Ran image classification (resnet50+cifar10)
> > > > Ran Operator Performance (opperf)
> > > >
> > > > On Thu, 19 Sep 2019 at 02:12, Tao Lv  wrote:
> > > >
> > > > > Hi community,
> > > > >
> > > > > Friendly reminder: it is less than 1.5 days remaining, so
> please take
> > > > your
> > > > > time to verify and vote.
> > > > >
> > > > > Thanks,
> > > > > -tao
> > > > >
> > > > > On Thu, Sep 19, 2019 at 3:06 PM Lin Yuan 
> > wrote:
> > > > >
> > > > > > +1
> > > > > > Tested Horovod on GPU
> > > > > >
> > > > > > On Wed, Sep 18, 2019 at 6:16 AM Zhao, Patric <
> > patric.z...@intel.com>
> > > > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > Tested MKLDNN backend and everything looks great.
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Qing Lan 
> > > > > > > > Sent: Wednesday, September 18, 2019 2:20 AM
> > > > > > > > To: dev@mxnet.incubator.apache.org
> > > > > > > > Subject: Re: [VOTE] Release Apache MXNet (incubating)
> 1.5.1.rc0
> > > > > > > >
> > > > > > > > +1 for Scala/Java test. Passed all tests for CPU/GPU
> build.
> > > > > > > > Also tested build from source with static build.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Qing
> > > > > > > > 
> > > > > > > > From: Tao Lv 
> > > > > > > > Sent: Tuesday, September 17, 2019 14:14
> > > > > > > > To: dev@mxnet.incubator.apache.org <
> > > 

Re: Code freeze for 1.5.1 patch release

[Carin Meier]

The Clojure jars have been built and put to staging

https://repository.apache.org/content/repositories/staging/org/apache/mxnet/contrib/clojure/clojure-mxnet-linux-cpu/1.5.1/
https://repository.apache.org/content/repositories/staging/org/apache/mxnet/contrib/clojure/clojure-mxnet-linux-gpu/1.5.1/
https://repository.apache.org/content/repositories/staging/org/apache/mxnet/contrib/clojure/clojure-mxnet-osx-cpu/1.5.1/

On Tue, Sep 17, 2019 at 2:21 PM Tao Lv  wrote:

> I have started the voting thread and move the language binding to after the
> vote passes.
> If someone has concerns about this decision, please comment in the voting
> thread.
>
> Thanks,
> -tao
>
> On Wed, Sep 18, 2019 at 1:09 AM Carin Meier  wrote:
>
> > To clarify, the Clojure source is included is the vote, the built jar is
> > not
> >
> > On Tue, Sep 17, 2019 at 1:08 PM Carin Meier 
> wrote:
> >
> > > We have done that on other releases. That is, vote without Clojure
> > > package. Someone feel free to clarify the official stance.
> > >
> > > On Tue, Sep 17, 2019 at 12:55 PM Lin Yuan  wrote:
> > >
> > >> Hi Tao,
> > >>
> > >> If the voting is on the source and not requiring the language
> bindings,
> > >> can
> > >> we do the voting in parallel with the release?
> > >>
> > >> Carin/Qing, please help to clarify if the R/Clojure language bindings
> > are
> > >> required for voting.
> > >>
> > >> Thanks,
> > >>
> > >> Lin
> > >>
> > >> On Tue, Sep 17, 2019 at 7:32 AM Tao Lv  wrote:
> > >>
> > >> > Thanks for your help, Carin. Per step 1.14 of  the release process
> > [1],
> > >> > stage repo links should be included in the voting email.
> > >> >
> > >> > Scala packages are done. Thanks to the help from @Lanking.
> > >> >
> > >> > We still have problem with R package on Windows. @yajiedesign is
> > >> helping on
> > >> > that.
> > >> >
> > >> > Again thanks for all of your support and patience.
> > >> >
> > >> > -tao
> > >> >
> > >> > [1]
> https://cwiki.apache.org/confluence/display/MXNET/Release+Process
> > >> >
> > >> > On Tue, Sep 17, 2019 at 6:10 PM Carin Meier 
> > >> wrote:
> > >> >
> > >> > > I will be able to build the Clojure packages on Friday. I don’t
> > >> believe
> > >> > > this needs to hold up the voting. I believe the voting is only on
> > the
> > >> > > source.
> > >> > >
> > >> > > -Carin
> > >> > >
> > >> > > On Mon, Sep 16, 2019 at 7:05 PM Lin Yuan 
> > wrote:
> > >> > >
> > >> > > > Hi Tao,
> > >> > > >
> > >> > > > Thanks for uploading the artifacts. May I know what the current
> > >> status
> > >> > of
> > >> > > > Scala, Clojure and R packages and any help you need from the
> > >> community
> > >> > to
> > >> > > > complete?
> > >> > > >
> > >> > > > Thanks,
> > >> > > >
> > >> > > > Lin
> > >> > > >
> > >> > > > On Fri, Sep 6, 2019 at 7:35 AM Tao Lv  wrote:
> > >> > > >
> > >> > > > > Update:
> > >> > > > >
> > >> > > > > Artifacts of 1.5.1.rc0 have been uploaded to github and Apache
> > >> dist.
> > >> > > > Before
> > >> > > > > voting, we still need some time to build packages for Scala,
> > >> Clojure
> > >> > > and
> > >> > > > R.
> > >> > > > >
> > >> > > > > Thank you for your patience.
> > >> > > > >
> > >> > > > > -tao
> > >> > > > >
> > >> > > > > On Thu, Sep 5, 2019 at 10:15 PM Tao Lv 
> > wrote:
> > >> > > > >
> > >> > > > > >
> > >> > > > > > Following the release process [1], I just created the tag
> for
> > >> > > 1.5.1.rc0
> > >> > > > > > [2]. Artifacts uploading and validation are still WIP. Will
> > keep
>

Re: Code freeze for 1.5.1 patch release

[Carin Meier]

To clarify, the Clojure source is included is the vote, the built jar is not

On Tue, Sep 17, 2019 at 1:08 PM Carin Meier  wrote:

> We have done that on other releases. That is, vote without Clojure
> package. Someone feel free to clarify the official stance.
>
> On Tue, Sep 17, 2019 at 12:55 PM Lin Yuan  wrote:
>
>> Hi Tao,
>>
>> If the voting is on the source and not requiring the language bindings,
>> can
>> we do the voting in parallel with the release?
>>
>> Carin/Qing, please help to clarify if the R/Clojure language bindings are
>> required for voting.
>>
>> Thanks,
>>
>> Lin
>>
>> On Tue, Sep 17, 2019 at 7:32 AM Tao Lv  wrote:
>>
>> > Thanks for your help, Carin. Per step 1.14 of  the release process [1],
>> > stage repo links should be included in the voting email.
>> >
>> > Scala packages are done. Thanks to the help from @Lanking.
>> >
>> > We still have problem with R package on Windows. @yajiedesign is
>> helping on
>> > that.
>> >
>> > Again thanks for all of your support and patience.
>> >
>> > -tao
>> >
>> > [1] https://cwiki.apache.org/confluence/display/MXNET/Release+Process
>> >
>> > On Tue, Sep 17, 2019 at 6:10 PM Carin Meier 
>> wrote:
>> >
>> > > I will be able to build the Clojure packages on Friday. I don’t
>> believe
>> > > this needs to hold up the voting. I believe the voting is only on the
>> > > source.
>> > >
>> > > -Carin
>> > >
>> > > On Mon, Sep 16, 2019 at 7:05 PM Lin Yuan  wrote:
>> > >
>> > > > Hi Tao,
>> > > >
>> > > > Thanks for uploading the artifacts. May I know what the current
>> status
>> > of
>> > > > Scala, Clojure and R packages and any help you need from the
>> community
>> > to
>> > > > complete?
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Lin
>> > > >
>> > > > On Fri, Sep 6, 2019 at 7:35 AM Tao Lv  wrote:
>> > > >
>> > > > > Update:
>> > > > >
>> > > > > Artifacts of 1.5.1.rc0 have been uploaded to github and Apache
>> dist.
>> > > > Before
>> > > > > voting, we still need some time to build packages for Scala,
>> Clojure
>> > > and
>> > > > R.
>> > > > >
>> > > > > Thank you for your patience.
>> > > > >
>> > > > > -tao
>> > > > >
>> > > > > On Thu, Sep 5, 2019 at 10:15 PM Tao Lv  wrote:
>> > > > >
>> > > > > >
>> > > > > > Following the release process [1], I just created the tag for
>> > > 1.5.1.rc0
>> > > > > > [2]. Artifacts uploading and validation are still WIP. Will keep
>> > you
>> > > > > > posted. Hopefully we can start the veto soon for a new release.
>> :)
>> > > > > >
>> > > > > > Let me know if you any question or suggestion for the release.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > -tao
>> > > > > >
>> > > > > > [1]
>> > > https://cwiki.apache.org/confluence/display/MXNET/Release+Process
>> > > > > > [2]
>> > https://github.com/apache/incubator-mxnet/releases/tag/1.5.1.rc0
>> > > > > >
>> > > > > >
>> > > > > > On Wed, Sep 4, 2019 at 9:23 AM Tao Lv  wrote:
>> > > > > >
>> > > > > >>
>> > > > > >> Code freezing!
>> > > > > >>
>> > > > > >> If you happen to be around github, please help to review the PR
>> > [1]
>> > > > for
>> > > > > >> bumping version strings on the release branch. Thanks.
>> > > > > >>
>> > > > > >> I will continue working on the rest steps for the release.
>> > > > > >>
>> > > > > >> Thanks,
>> > > > > >> -tao
>> > > > > >>
>> > > > > >> [1] https://github.com/apache/incubator-mxnet/pull/16072
>> > > > > >>
>> > > > > >> On Mon, Sep 2, 2019 at 9:51 PM Tao Lv 
>> wrote:
>> > > > > >>
>> > > > > >>>
>> > > > > >>> I drafted the release notes for 1.5.1 patch release:
>> > > > > >>>
>> > > >
>> https://cwiki.apache.org/confluence/display/MXNET/1.5.1+Release+Notes
>> > > > > >>>
>> > > > > >>> Any comments or suggestions are highly appreciated!
>> > > > > >>>
>> > > > > >>> -tao
>> > > > > >>>
>> > > > > >>> On Mon, Sep 2, 2019 at 2:00 PM kellen sunderland <
>> > > > > >>> kellen.sunderl...@gmail.com> wrote:
>> > > > > >>>
>> > > > > >>>> Thanks for organizing the release Tao.
>> > > > > >>>>
>> > > > > >>>> On Sun, Sep 1, 2019, 5:53 PM Tao Lv 
>> wrote:
>> > > > > >>>>
>> > > > > >>>> > Hi Community,
>> > > > > >>>> >
>> > > > > >>>> > Code freeze for 1.5.1 patch release will be 9/3 6pm PST
>> (9/4
>> > 9am
>> > > > > >>>> CST). If
>> > > > > >>>> > you have any additional fix in progress and would like to
>> > > include
>> > > > it
>> > > > > >>>> in
>> > > > > >>>> > this release, please assure they have been merged before
>> code
>> > > > > freeze.
>> > > > > >>>> >
>> > > > > >>>> > Thanks for all your support and contribution.
>> > > > > >>>> >
>> > > > > >>>> > -tao
>> > > > > >>>> >
>> > > > > >>>>
>> > > > > >>>
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: Code freeze for 1.5.1 patch release

[Carin Meier]

We have done that on other releases. That is, vote without Clojure package.
Someone feel free to clarify the official stance.

On Tue, Sep 17, 2019 at 12:55 PM Lin Yuan  wrote:

> Hi Tao,
>
> If the voting is on the source and not requiring the language bindings, can
> we do the voting in parallel with the release?
>
> Carin/Qing, please help to clarify if the R/Clojure language bindings are
> required for voting.
>
> Thanks,
>
> Lin
>
> On Tue, Sep 17, 2019 at 7:32 AM Tao Lv  wrote:
>
> > Thanks for your help, Carin. Per step 1.14 of  the release process [1],
> > stage repo links should be included in the voting email.
> >
> > Scala packages are done. Thanks to the help from @Lanking.
> >
> > We still have problem with R package on Windows. @yajiedesign is helping
> on
> > that.
> >
> > Again thanks for all of your support and patience.
> >
> > -tao
> >
> > [1] https://cwiki.apache.org/confluence/display/MXNET/Release+Process
> >
> > On Tue, Sep 17, 2019 at 6:10 PM Carin Meier 
> wrote:
> >
> > > I will be able to build the Clojure packages on Friday. I don’t believe
> > > this needs to hold up the voting. I believe the voting is only on the
> > > source.
> > >
> > > -Carin
> > >
> > > On Mon, Sep 16, 2019 at 7:05 PM Lin Yuan  wrote:
> > >
> > > > Hi Tao,
> > > >
> > > > Thanks for uploading the artifacts. May I know what the current
> status
> > of
> > > > Scala, Clojure and R packages and any help you need from the
> community
> > to
> > > > complete?
> > > >
> > > > Thanks,
> > > >
> > > > Lin
> > > >
> > > > On Fri, Sep 6, 2019 at 7:35 AM Tao Lv  wrote:
> > > >
> > > > > Update:
> > > > >
> > > > > Artifacts of 1.5.1.rc0 have been uploaded to github and Apache
> dist.
> > > > Before
> > > > > voting, we still need some time to build packages for Scala,
> Clojure
> > > and
> > > > R.
> > > > >
> > > > > Thank you for your patience.
> > > > >
> > > > > -tao
> > > > >
> > > > > On Thu, Sep 5, 2019 at 10:15 PM Tao Lv  wrote:
> > > > >
> > > > > >
> > > > > > Following the release process [1], I just created the tag for
> > > 1.5.1.rc0
> > > > > > [2]. Artifacts uploading and validation are still WIP. Will keep
> > you
> > > > > > posted. Hopefully we can start the veto soon for a new release.
> :)
> > > > > >
> > > > > > Let me know if you any question or suggestion for the release.
> > > > > >
> > > > > > Thanks,
> > > > > > -tao
> > > > > >
> > > > > > [1]
> > > https://cwiki.apache.org/confluence/display/MXNET/Release+Process
> > > > > > [2]
> > https://github.com/apache/incubator-mxnet/releases/tag/1.5.1.rc0
> > > > > >
> > > > > >
> > > > > > On Wed, Sep 4, 2019 at 9:23 AM Tao Lv  wrote:
> > > > > >
> > > > > >>
> > > > > >> Code freezing!
> > > > > >>
> > > > > >> If you happen to be around github, please help to review the PR
> > [1]
> > > > for
> > > > > >> bumping version strings on the release branch. Thanks.
> > > > > >>
> > > > > >> I will continue working on the rest steps for the release.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> -tao
> > > > > >>
> > > > > >> [1] https://github.com/apache/incubator-mxnet/pull/16072
> > > > > >>
> > > > > >> On Mon, Sep 2, 2019 at 9:51 PM Tao Lv  wrote:
> > > > > >>
> > > > > >>>
> > > > > >>> I drafted the release notes for 1.5.1 patch release:
> > > > > >>>
> > > >
> https://cwiki.apache.org/confluence/display/MXNET/1.5.1+Release+Notes
> > > > > >>>
> > > > > >>> Any comments or suggestions are highly appreciated!
> > > > > >>>
> > > > > >>> -tao
> > > > > >>>
> > > > > >>> On Mon, Sep 2, 2019 at 2:00 PM kellen sunderland <
> > > > > >>> kellen.sunderl...@gmail.com> wrote:
> > > > > >>>
> > > > > >>>> Thanks for organizing the release Tao.
> > > > > >>>>
> > > > > >>>> On Sun, Sep 1, 2019, 5:53 PM Tao Lv  wrote:
> > > > > >>>>
> > > > > >>>> > Hi Community,
> > > > > >>>> >
> > > > > >>>> > Code freeze for 1.5.1 patch release will be 9/3 6pm PST (9/4
> > 9am
> > > > > >>>> CST). If
> > > > > >>>> > you have any additional fix in progress and would like to
> > > include
> > > > it
> > > > > >>>> in
> > > > > >>>> > this release, please assure they have been merged before
> code
> > > > > freeze.
> > > > > >>>> >
> > > > > >>>> > Thanks for all your support and contribution.
> > > > > >>>> >
> > > > > >>>> > -tao
> > > > > >>>> >
> > > > > >>>>
> > > > > >>>
> > > > >
> > > >
> > >
> >
>

Re: Code freeze for 1.5.1 patch release

[Carin Meier]

I will be able to build the Clojure packages on Friday. I don’t believe
this needs to hold up the voting. I believe the voting is only on the
source.

-Carin

On Mon, Sep 16, 2019 at 7:05 PM Lin Yuan  wrote:

> Hi Tao,
>
> Thanks for uploading the artifacts. May I know what the current status of
> Scala, Clojure and R packages and any help you need from the community to
> complete?
>
> Thanks,
>
> Lin
>
> On Fri, Sep 6, 2019 at 7:35 AM Tao Lv  wrote:
>
> > Update:
> >
> > Artifacts of 1.5.1.rc0 have been uploaded to github and Apache dist.
> Before
> > voting, we still need some time to build packages for Scala, Clojure and
> R.
> >
> > Thank you for your patience.
> >
> > -tao
> >
> > On Thu, Sep 5, 2019 at 10:15 PM Tao Lv  wrote:
> >
> > >
> > > Following the release process [1], I just created the tag for 1.5.1.rc0
> > > [2]. Artifacts uploading and validation are still WIP. Will keep you
> > > posted. Hopefully we can start the veto soon for a new release. :)
> > >
> > > Let me know if you any question or suggestion for the release.
> > >
> > > Thanks,
> > > -tao
> > >
> > > [1] https://cwiki.apache.org/confluence/display/MXNET/Release+Process
> > > [2] https://github.com/apache/incubator-mxnet/releases/tag/1.5.1.rc0
> > >
> > >
> > > On Wed, Sep 4, 2019 at 9:23 AM Tao Lv  wrote:
> > >
> > >>
> > >> Code freezing!
> > >>
> > >> If you happen to be around github, please help to review the PR [1]
> for
> > >> bumping version strings on the release branch. Thanks.
> > >>
> > >> I will continue working on the rest steps for the release.
> > >>
> > >> Thanks,
> > >> -tao
> > >>
> > >> [1] https://github.com/apache/incubator-mxnet/pull/16072
> > >>
> > >> On Mon, Sep 2, 2019 at 9:51 PM Tao Lv  wrote:
> > >>
> > >>>
> > >>> I drafted the release notes for 1.5.1 patch release:
> > >>>
> https://cwiki.apache.org/confluence/display/MXNET/1.5.1+Release+Notes
> > >>>
> > >>> Any comments or suggestions are highly appreciated!
> > >>>
> > >>> -tao
> > >>>
> > >>> On Mon, Sep 2, 2019 at 2:00 PM kellen sunderland <
> > >>> kellen.sunderl...@gmail.com> wrote:
> > >>>
> >  Thanks for organizing the release Tao.
> > 
> >  On Sun, Sep 1, 2019, 5:53 PM Tao Lv  wrote:
> > 
> >  > Hi Community,
> >  >
> >  > Code freeze for 1.5.1 patch release will be 9/3 6pm PST (9/4 9am
> >  CST). If
> >  > you have any additional fix in progress and would like to include
> it
> >  in
> >  > this release, please assure they have been merged before code
> > freeze.
> >  >
> >  > Thanks for all your support and contribution.
> >  >
> >  > -tao
> >  >
> > 
> > >>>
> >
>

Another Gluon Brand

[Carin Meier]

Gluon came up in one of my feeds in the context https://gluonhq.com/ of
mobile solutions.

Thought I would bring it to the attention of the group in case it's
relevant to branding discussions.

- Carin

Re: MXNet CI repository

[Carin Meier]

+1

On Thu, Aug 15, 2019 at 2:37 PM Chaitanya Bapat 
wrote:

> +1
> LGTM!
>
> On Thu, 15 Aug 2019 at 11:01, Marco de Abreu 
> wrote:
>
> > Hello,
> >
> > I'd like to propose a repository where CI infrastructure code can be
> > stored. I'd propose "incubator-mxnet-ci". Is everybody fine with that
> name
> > or has a better idea?
> >
> > Best regards
> > Marco
> >
>
>
> --
> *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]
> 
>

Re: CI and PRs

[Carin Meier]

If a language binding test is failing for a not important reason, then it
is too brittle and needs to be fixed (we have fixed some of these with the
Clojure package [1]).
But in general, if we thinking of the MXNet project as one project that is
across all the language bindings, then we want to know if some fundamental
code change is going to break a downstream package.
I can't speak for all the high level package binding maintainers, but I'm
always happy to pitch in to provide code fixes to help the base PR get
green.

The time costs to maintain such a large CI project obviously needs to be
considered as well.

[1] https://github.com/apache/incubator-mxnet/pull/15579

On Wed, Aug 14, 2019 at 3:48 PM Pedro Larroy 
wrote:

> From what I have seen Clojure is 15 minutes, which I think is reasonable.
> The only question is that when a binding such as R, Perl or Clojure fails,
> some devs are a bit confused about how to fix them since they are not
> familiar with the testing tools and the language.
>
> On Wed, Aug 14, 2019 at 11:57 AM Carin Meier  wrote:
>
> > Great idea Marco! Anything that you think would be valuable to share
> would
> > be good. The duration of each node in the test stage sounds like a good
> > start.
> >
> > - Carin
> >
> > On Wed, Aug 14, 2019 at 2:48 PM Marco de Abreu 
> > wrote:
> >
> > > Hi,
> > >
> > > we record a bunch of metrics about run statistics (down to the duration
> > of
> > > every individual step). If you tell me which ones you're particularly
> > > interested in (probably total duration of each node in the test stage),
> > I'm
> > > happy to provide them.
> > >
> > > Dimensions are (in hierarchical order):
> > > - job
> > > - branch
> > > - stage
> > > - node
> > > - step
> > >
> > > Unfortunately I don't have the possibility to export them since we
> store
> > > them in CloudWatch Metrics which afaik doesn't offer raw exports.
> > >
> > > Best regards,
> > > Marco
> > >
> > > Carin Meier  schrieb am Mi., 14. Aug. 2019,
> 19:43:
> > >
> > > > I would prefer to keep the language binding in the PR process.
> Perhaps
> > we
> > > > could do some analytics to see how much each of the language bindings
> > is
> > > > contributing to overall run time.
> > > > If we have some metrics on that, maybe we can come up with a
> guideline
> > of
> > > > how much time each should take. Another possibility is leverage the
> > > > parallel builds more.
> > > >
> > > > On Wed, Aug 14, 2019 at 1:30 PM Pedro Larroy <
> > > pedro.larroy.li...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hi Carin.
> > > > >
> > > > > That's a good point, all things considered would your preference be
> > to
> > > > keep
> > > > > the Clojure tests as part of the PR process or in Nightly?
> > > > > Some options are having notifications here or in slack. But if we
> > think
> > > > > breakages would go unnoticed maybe is not a good idea to fully
> remove
> > > > > bindings from the PR process and just streamline the process.
> > > > >
> > > > > Pedro.
> > > > >
> > > > > On Wed, Aug 14, 2019 at 5:09 AM Carin Meier 
> > > > wrote:
> > > > >
> > > > > > Before any binding tests are moved to nightly, I think we need to
> > > > figure
> > > > > > out how the community can get proper notifications of failure and
> > > > success
> > > > > > on those nightly runs. Otherwise, I think that breakages would go
> > > > > > unnoticed.
> > > > > >
> > > > > > -Carin
> > > > > >
> > > > > > On Tue, Aug 13, 2019 at 7:47 PM Pedro Larroy <
> > > > > pedro.larroy.li...@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > Seems we are hitting some problems in CI. I propose the
> following
> > > > > action
> > > > > > > items to remedy the situation and accelerate turn around times
> in
> > > CI,
> > > > > > > reduce cost, complexity and probability of failure blocking PRs
> > and
> > > > > > > frustrat

Re: CI and PRs

[Carin Meier]

Great idea Marco! Anything that you think would be valuable to share would
be good. The duration of each node in the test stage sounds like a good
start.

- Carin

On Wed, Aug 14, 2019 at 2:48 PM Marco de Abreu 
wrote:

> Hi,
>
> we record a bunch of metrics about run statistics (down to the duration of
> every individual step). If you tell me which ones you're particularly
> interested in (probably total duration of each node in the test stage), I'm
> happy to provide them.
>
> Dimensions are (in hierarchical order):
> - job
> - branch
> - stage
> - node
> - step
>
> Unfortunately I don't have the possibility to export them since we store
> them in CloudWatch Metrics which afaik doesn't offer raw exports.
>
> Best regards,
> Marco
>
> Carin Meier  schrieb am Mi., 14. Aug. 2019, 19:43:
>
> > I would prefer to keep the language binding in the PR process. Perhaps we
> > could do some analytics to see how much each of the language bindings is
> > contributing to overall run time.
> > If we have some metrics on that, maybe we can come up with a guideline of
> > how much time each should take. Another possibility is leverage the
> > parallel builds more.
> >
> > On Wed, Aug 14, 2019 at 1:30 PM Pedro Larroy <
> pedro.larroy.li...@gmail.com
> > >
> > wrote:
> >
> > > Hi Carin.
> > >
> > > That's a good point, all things considered would your preference be to
> > keep
> > > the Clojure tests as part of the PR process or in Nightly?
> > > Some options are having notifications here or in slack. But if we think
> > > breakages would go unnoticed maybe is not a good idea to fully remove
> > > bindings from the PR process and just streamline the process.
> > >
> > > Pedro.
> > >
> > > On Wed, Aug 14, 2019 at 5:09 AM Carin Meier 
> > wrote:
> > >
> > > > Before any binding tests are moved to nightly, I think we need to
> > figure
> > > > out how the community can get proper notifications of failure and
> > success
> > > > on those nightly runs. Otherwise, I think that breakages would go
> > > > unnoticed.
> > > >
> > > > -Carin
> > > >
> > > > On Tue, Aug 13, 2019 at 7:47 PM Pedro Larroy <
> > > pedro.larroy.li...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hi
> > > > >
> > > > > Seems we are hitting some problems in CI. I propose the following
> > > action
> > > > > items to remedy the situation and accelerate turn around times in
> CI,
> > > > > reduce cost, complexity and probability of failure blocking PRs and
> > > > > frustrating developers:
> > > > >
> > > > > * Upgrade Windows visual studio from VS 2015 to VS 2017. The
> > > > > build_windows.py infrastructure should easily work with the new
> > > version.
> > > > > Currently some PRs are blocked by this:
> > > > > https://github.com/apache/incubator-mxnet/issues/13958
> > > > > * Move Gluon Model zoo tests to nightly. Tracked at
> > > > > https://github.com/apache/incubator-mxnet/issues/15295
> > > > > * Move non-python bindings tests to nightly. If a commit is
> touching
> > > > other
> > > > > bindings, the reviewer should ask for a full run which can be done
> > > > locally,
> > > > > use the label bot to trigger a full CI build, or defer to nightly.
> > > > > * Provide a couple of basic sanity performance tests on small
> models
> > > that
> > > > > are run on CI and can be echoed by the label bot as a comment for
> > PRs.
> > > > > * Address unit tests that take more than 10-20s, streamline them or
> > > move
> > > > > them to nightly if it can't be done.
> > > > > * Open sourcing the remaining CI infrastructure scripts so the
> > > community
> > > > > can contribute.
> > > > >
> > > > > I think our goal should be turnaround under 30min.
> > > > >
> > > > > I would also like to touch base with the community that some PRs
> are
> > > not
> > > > > being followed up by committers asking for changes. For example
> this
> > PR
> > > > is
> > > > > importtant and is hanging for a long time.
> > > > >
> > > > > https://github.com/apache/incubator-mxnet/pull/15051
> > > > >
> > > > > This is another, less important but more trivial to review:
> > > > >
> > > > > https://github.com/apache/incubator-mxnet/pull/14940
> > > > >
> > > > > I think comitters requesting changes and not folllowing up in
> > > reasonable
> > > > > time is not healthy for the project. I suggest configuring github
> > > > > Notifications for a good SNR and following up.
> > > > >
> > > > > Regards.
> > > > >
> > > > > Pedro.
> > > > >
> > > >
> > >
> >
>

Re: CI and PRs

[Carin Meier]

I would prefer to keep the language binding in the PR process. Perhaps we
could do some analytics to see how much each of the language bindings is
contributing to overall run time.
If we have some metrics on that, maybe we can come up with a guideline of
how much time each should take. Another possibility is leverage the
parallel builds more.

On Wed, Aug 14, 2019 at 1:30 PM Pedro Larroy 
wrote:

> Hi Carin.
>
> That's a good point, all things considered would your preference be to keep
> the Clojure tests as part of the PR process or in Nightly?
> Some options are having notifications here or in slack. But if we think
> breakages would go unnoticed maybe is not a good idea to fully remove
> bindings from the PR process and just streamline the process.
>
> Pedro.
>
> On Wed, Aug 14, 2019 at 5:09 AM Carin Meier  wrote:
>
> > Before any binding tests are moved to nightly, I think we need to figure
> > out how the community can get proper notifications of failure and success
> > on those nightly runs. Otherwise, I think that breakages would go
> > unnoticed.
> >
> > -Carin
> >
> > On Tue, Aug 13, 2019 at 7:47 PM Pedro Larroy <
> pedro.larroy.li...@gmail.com
> > >
> > wrote:
> >
> > > Hi
> > >
> > > Seems we are hitting some problems in CI. I propose the following
> action
> > > items to remedy the situation and accelerate turn around times in CI,
> > > reduce cost, complexity and probability of failure blocking PRs and
> > > frustrating developers:
> > >
> > > * Upgrade Windows visual studio from VS 2015 to VS 2017. The
> > > build_windows.py infrastructure should easily work with the new
> version.
> > > Currently some PRs are blocked by this:
> > > https://github.com/apache/incubator-mxnet/issues/13958
> > > * Move Gluon Model zoo tests to nightly. Tracked at
> > > https://github.com/apache/incubator-mxnet/issues/15295
> > > * Move non-python bindings tests to nightly. If a commit is touching
> > other
> > > bindings, the reviewer should ask for a full run which can be done
> > locally,
> > > use the label bot to trigger a full CI build, or defer to nightly.
> > > * Provide a couple of basic sanity performance tests on small models
> that
> > > are run on CI and can be echoed by the label bot as a comment for PRs.
> > > * Address unit tests that take more than 10-20s, streamline them or
> move
> > > them to nightly if it can't be done.
> > > * Open sourcing the remaining CI infrastructure scripts so the
> community
> > > can contribute.
> > >
> > > I think our goal should be turnaround under 30min.
> > >
> > > I would also like to touch base with the community that some PRs are
> not
> > > being followed up by committers asking for changes. For example this PR
> > is
> > > importtant and is hanging for a long time.
> > >
> > > https://github.com/apache/incubator-mxnet/pull/15051
> > >
> > > This is another, less important but more trivial to review:
> > >
> > > https://github.com/apache/incubator-mxnet/pull/14940
> > >
> > > I think comitters requesting changes and not folllowing up in
> reasonable
> > > time is not healthy for the project. I suggest configuring github
> > > Notifications for a good SNR and following up.
> > >
> > > Regards.
> > >
> > > Pedro.
> > >
> >
>

Re: CI and PRs

[Carin Meier]

Before any binding tests are moved to nightly, I think we need to figure
out how the community can get proper notifications of failure and success
on those nightly runs. Otherwise, I think that breakages would go unnoticed.

-Carin

On Tue, Aug 13, 2019 at 7:47 PM Pedro Larroy 
wrote:

> Hi
>
> Seems we are hitting some problems in CI. I propose the following action
> items to remedy the situation and accelerate turn around times in CI,
> reduce cost, complexity and probability of failure blocking PRs and
> frustrating developers:
>
> * Upgrade Windows visual studio from VS 2015 to VS 2017. The
> build_windows.py infrastructure should easily work with the new version.
> Currently some PRs are blocked by this:
> https://github.com/apache/incubator-mxnet/issues/13958
> * Move Gluon Model zoo tests to nightly. Tracked at
> https://github.com/apache/incubator-mxnet/issues/15295
> * Move non-python bindings tests to nightly. If a commit is touching other
> bindings, the reviewer should ask for a full run which can be done locally,
> use the label bot to trigger a full CI build, or defer to nightly.
> * Provide a couple of basic sanity performance tests on small models that
> are run on CI and can be echoed by the label bot as a comment for PRs.
> * Address unit tests that take more than 10-20s, streamline them or move
> them to nightly if it can't be done.
> * Open sourcing the remaining CI infrastructure scripts so the community
> can contribute.
>
> I think our goal should be turnaround under 30min.
>
> I would also like to touch base with the community that some PRs are not
> being followed up by committers asking for changes. For example this PR is
> importtant and is hanging for a long time.
>
> https://github.com/apache/incubator-mxnet/pull/15051
>
> This is another, less important but more trivial to review:
>
> https://github.com/apache/incubator-mxnet/pull/14940
>
> I think comitters requesting changes and not folllowing up in reasonable
> time is not healthy for the project. I suggest configuring github
> Notifications for a good SNR and following up.
>
> Regards.
>
> Pedro.
>

Re: [DISCUSS] Make MXNet deploy it's own distribution

[Carin Meier]

>From the Clojure package perspective, since it is compatible with maven,
this approach will work fine.
It would also make it easier for developers to build on top of MXNet and
share their libraries.

- Carin

On Wed, Jul 3, 2019 at 3:45 AM Per da Silva  wrote:

> Hi,
>
> We've started working on something along these lines as part of the CD
> pipeline framework. The idea is to compile and test the libmxnet.so  (both
> statically and dynamically linked) for the different variants (cpu, gpu,
> mkl, etc.) then have the different mxnet frontends (python, Julia, scala,
> etc) just wrap around the library.
>
> I've been on long term sick leave and haven't been able to move forward
> with this, although I have an open PR that kicks off this work:
> https://github.com/apache/incubator-mxnet/pull/15051 - I welcome everyone
> to take a look. It's the first of a series of PRs to automate the
> distribution of the python (pip and docker) packages. Instead of using
> maven, we have opted to use S3. But this decision can be revisited.
>
> We also want to distribute what we termed "runtime" docker images. Docker
> images containing the dynamically linked mxnet library and all of the
> runtime dependencies (examples: https://hub.docker.com/r/mxnet/runtime).
> This could facilitate the packaging and distribution of docker images for
> the different frontends.
>
> Cheers,
>
> Per
>
> On Wed., 3 Jul. 2019, 8:47 am Qing Lan,  wrote:
>
> > In that case, the answer is yes. The Scala package will be published in
> > one version with a variaty of backend package choices. User can easily
> > attach and detach different MXNet versions. However, the Scala package
> > cannot run without a backend.
> >
> > Another key advantage of this design will be a broader support on
> > different implementations such as Java Cpp. User will be able to
> implement
> > their customized MXNet frontend to use the native library.
> >
> > Thanks,
> > Qing
> >
> > 
> > From: Sheng Zha 
> > Sent: Tuesday, July 2, 2019 22:14
> > To: dev@mxnet.incubator.apache.org
> > Subject: Re: [DISCUSS] Make MXNet deploy it's own distribution
> >
> > Does it mean that the scala binding of mxnet will be an independent
> > package that doesn’t directly depend on the native package, and user
> > projects need to declare dependency on both the scala binding and one of
> > the native packages?
> >
> > -sz
> >
> > > On Jul 2, 2019, at 5:50 PM, Frank Liu  wrote:
> > >
> > > Currently, MXNet were built along with different language bindings such
> > as
> > > Scala.
> > >
> > > The libmxnet.so files are bundled within scala jar package.
> > >
> > > It would be nice to distribute libmxnet.so library independently in
> > maven,
> > > and scala package can choose which native library to use.
> > >
> > > Here is the design document on cwiki:
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Make+MXNet+deploy+it%27s+own+distribution
> > >
> > > Thanks,
> > >
> > > Frank
> >
>

[Announcement] New Committer - Kedar Bellare

[Carin Meier]

Please join me in welcoming Kedar Belllare https://github.com/kedarbellare as
a new committer.

Kedar has worked on the Clojure package and helped improve it by porting
the Scala image and infer functionality to Clojure as well as adding
examples. He also is the main driver of the new Clojure API
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103092678

We look forward to his continued involvement and contributions.

- Carin
on behalf of Apache MXNet PPMC

Re: [ANNOUNCEMENT] New Committer: Przemyslaw Tredak (ptrendx)

[Carin Meier]

Welcome!

On Tue, May 21, 2019 at 5:32 PM Naveen Swamy  wrote:

> The Project Podling Management Committee (PPMC) for Apache MXNet has
> invited Przemyslaw Tredak (ptrendx) based on his contribution to MXNet to
> become a committer and we are pleased to announce that he has accepted.
>
> Przemyslaw, thanks a lot for your contribution and continued effort to
> support MXNet community.
>
> Please join me in welcoming Przemyslaw to the project!
>
> Thanks, Naveen
> (on behalf of Apache MXNet PPMC)
>

Re: New PMC member: Dick Carter

[Carin Meier]

Congrats and welcome!

On Tue, May 21, 2019 at 4:37 PM Marco de Abreu 
wrote:

> The Project Management Committee (PMC) for Apache MXNet
> has invited Dick Carter to become a PMC member and we are pleased
> to announce that he has accepted.
>
> Dick has been a great help over the past years to make MXNet as
> efficient and easy-to-use on GPU as possible, reduce technical debt,
> improve our testing experience around flaky tests and providing senior
> guidance within the project.
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
> Being a PMC member enables assistance with the management
> and to guide the direction of the project.
>
> Best regards,
> Marco de Abreu
>

Re: [Announcement] New Committer - Zach Kimberg

[Carin Meier]

Congrats!

On Thu, May 9, 2019 at 1:41 PM Per da Silva  wrote:

> Nice one! Congratulations =)
>
> On Thu, May 9, 2019 at 7:38 PM Jake Lee  wrote:
>
> > Congrat!
> >
> > On Thu, May 9, 2019 at 10:37 AM Yuan Tang 
> wrote:
> >
> > > Welcome!
> > >
> > > On Thu, May 9, 2019 at 1:36 PM Marco de Abreu  >
> > > wrote:
> > >
> > > > Welcome!
> > > >
> > > > Hagay Lupesko  schrieb am Do., 9. Mai 2019,
> 19:33:
> > > >
> > > > > Congratulations Zach - well deserved!
> > > > >
> > > > > On Thu, May 9, 2019, 13:26 Qing Lan  wrote:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > Please join me in welcoming Zach Kimberg (
> > https://github.com/zachgk)
> > > > as
> > > > > a
> > > > > > new committer.
> > > > > >
> > > > > > He has been solving some important bugs in MXNet JVM with respect
> > to
> > > > > usage
> > > > > > improvement, build issues and a lot more. He also created the
> > Jenkins
> > > > > based
> > > > > > publish pipeline for us to have standard way to build and test
> > > > > > static-linked package conveniently for everyone in the community.
> > > > > Moreover,
> > > > > > he solved a bunch of License problems we have in MXNet and
> brought
> > > > > several
> > > > > > fixes to let us get 1.4.0 release on time.
> > > > > >
> > > > > > Thanks,
> > > > > > Qing
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.1.rc0

[Carin Meier]

+ 1 (binding)

Built Scala/ Clojure and ran tests

On Wed, May 1, 2019 at 7:06 PM Aaron Markham 
wrote:

> Make that +1 (non-binding)
>
> On Wed, May 1, 2019 at 3:42 PM Aaron Markham 
> wrote:
> >
> > +1 (binding)
> >
> > * Built with GPU and tested the first part of the ssd example.
> > * Built with GPU / cross-compiled to arm8 for Jetson.
> > * Built Scala/Java on top of the cross-compiled arm8 (ran into trouble
> > here, but I think this is not popular enough yet to derail things,
> > plus there are workarounds)
> > * Built on CPU instance and tested docs.
> > http://34.201.8.176/versions/1.4.1/api/python/io/io.html
> > I don't see anything specific being different in this patch for docs,
> > so hard to tell if there's an issue. I'll assume not given the
> > successful generation of the API docs.
> >
> >
> > On Wed, May 1, 2019 at 1:28 PM Pedro Larroy
> >  wrote:
> > >
> > > +1 (non-binding)
> > >
> > > Tried CPU build + C++ tests + 714 Python unit tests in 605s.
> > > ARMv7 build + small unit test in QEMU + ARMv8 builds.
> > >
> > > Thanks. Regards
> > >
> > > Pedro.
> > >
> > > On Wed, May 1, 2019 at 10:41 AM Qing Lan  wrote:
> > > >
> > > > +1 (binding)
> > > >
> > > > build from source works for OSX and Ubuntu CPU
> > > > Scala build/test successfully with Dynamic link and static link.
> > > >
> > > > Thanks,
> > > > Qing
> > > >
> > > > 
> > > > From: Sheng Zha 
> > > > Sent: Wednesday, May 1, 2019 13:14
> > > > To: d...@mxnet.apache.org
> > > > Subject: Re: [VOTE] Release Apache MXNet (incubating) version
> 1.4.1.rc0
> > > >
> > > > Hi all,
> > > >
> > > > Reminder that the vote for 1.4.1 release is still ongoing. If you
> can, please help out. Thank you.
> > > >
> > > > -sz
> > > >
> > > > On 2019/04/30 06:51:45, Junru Shao  wrote:
> > > > > Dear MXNet community,
> > > > >
> > > > > This is the 3-day vote to release Apache MXNet (incubating)
> version v1.4.1.
> > > > > The voting on dev@ list will start Apr 29 23:59:59 (PST) and
> close on May
> > > > > 02 23:59:59.
> > > > >
> > > > > Below are links to
> > > > > 1) Release notes:
> > > > >
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.1+Release+Notes
> > > > > .
> > > > > 2) Release Candidate:
> > > > > https://github.com/apache/incubator-mxnet/releases/tag/1.4.1.rc0.
> > > > > 3) Source and signatures on Apache dist server:
> > > > > https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.1.rc0/.
> > > > >
> > > > > Please remember to TEST first before voting accordingly:
> > > > > +1 = approve
> > > > > +0 = no opinion
> > > > > -1 = disapprove (provide reason)
> > > > >
> > > > > Best regards,
> > > > > Junru Shao
> > > > >
>

Re: Clojure MXNet Monthly Update

[Carin Meier]

Thanks for the feedback. I remember a wiki page for the monthly updates but
I can't remember the exact location. Does anyone have a link handy?

I would be happy to add the updates to a Clojure section of the "main" one.
I will most likely continue to put out a targeted one for the Clojure
community as well, since I think that is valuable. Not to mention the fact,
I don't think my cat pictures would work in the main document :)

- Carin

On Mon, Apr 29, 2019 at 3:36 PM Pedro Larroy 
wrote:

> nice!  I would suggest that we use the medium account for MXNet and
> have a "this month in MXNet" as they do in other open source projects
> and just have a clojure section? I think it gives nice visibility to
> the project and attracts contributors. Maybe just copy your updates to
> the "main one"?
>
> Pedro.
>
>
> On Fri, Apr 26, 2019 at 1:45 PM Carin Meier  wrote:
> >
> > I've started a monthly blog update targeted for the Clojure community
> but I
> > thought I would share it here too :)
> >
> > http://gigasquidsoftware.com/blog/2019/04/26/clojure-mxnet-april-update/
> >
> > http://gigasquidsoftware.com/blog/2019/03/22/clojure-mxnet-march-update/
> >
> > Best,
> > Carin
>

Clojure MXNet Monthly Update

[Carin Meier]

I've started a monthly blog update targeted for the Clojure community but I
thought I would share it here too :)

http://gigasquidsoftware.com/blog/2019/04/26/clojure-mxnet-april-update/

http://gigasquidsoftware.com/blog/2019/03/22/clojure-mxnet-march-update/

Best,
Carin

ICLR meetup?

[Carin Meier]

Anyone planning on going to https://iclr.cc/ ?

I'll be there and wondering if anyone that was going is interested in a
meetup or just informal get together?

- Carin

Re: [Announcement] New Committer - Wang Jiajun

[Carin Meier]

Congrats!

On Tue, Apr 16, 2019 at 11:58 AM Anirudh Subramanian 
wrote:

> Hi,
>
> Please join me to welcome Wang Jiajun (https://github.com/arcadiaphy) as a
> new committer of Apache (incubating) MXNet!
>
> Wang has been solving some tough bugs with respect to memory leaks, process
> fork handling, dependency engine issues and custom op exception handling.
>
> Issue Involvement:
>
> https://github.com/apache/incubator-mxnet/issues?utf8=%E2%9C%93=is%3Aissue+involves%3Aarcadiaphy
>
> PRs authored:
>
> https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+author%3Aarcadiaphy+
>
> Anirudh
>

Re: [Announcement] New Committer - Alex Zai

[Carin Meier]

Welcome and congrats!

On Sun, Mar 31, 2019 at 12:48 PM Anirudh Subramanian 
wrote:

> Hi all,
>
> Please join me to welcome Alex Zai as a new committer of Apache
> (incubating) MXNet!
>
> Alex has been instrumental in brining MKLDNN from experimental to making it
> default on MXNet master. This involved adding Python and C++ unit tests,
> improving CI coverage for MKLDNN, testing MKLDNN on different platforms and
> working on issues related to MKLDNN.
>
> PRs:
>
> https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+author%3Aazai91+
>
> Issues:
>
> https://github.com/apache/incubator-mxnet/issues?utf8=%E2%9C%93=is%3Aissue+involves%3Aazai91
>
> Reviews:
>
> https://github.com/apache/incubator-mxnet/pulls?page=1=is%3Apr+reviewed-by%3Aazai91=%E2%9C%93
>
> Dev:
> https://lists.apache.org/list.html?d...@mxnet.apache.org:lte=3y:azai91
>
> Thanks,
>
> Anirudh
>

Re: The Learning Robot

[Carin Meier]

done :)

On Fri, Mar 29, 2019 at 12:31 PM Anton Chernov  wrote:

> Thank you!
>
> Maybe you can retweet mine:
>
> https://twitter.com/lebegus/status/556984824885249
>
> And ApacheMXNet could do that afterwards as well?
>
> Anton
>
> пт, 29 мар. 2019 г. в 14:06, Carin Meier :
>
> > Great story!
> >
> > I would love to retweet it on twitter. Is there anyway to get it out on
> the
> > https://twitter.com/ApacheMXNet account?
> >
> > - Carin
> >
> > On Fri, Mar 29, 2019 at 6:37 AM Anton Chernov 
> wrote:
> >
> > > Dear MXNet Community,
> > >
> > >
> > > Read the development story of a robotics demo powered by deep learning
> > with
> > > Apache MXNet on an embedded platform.
> > >
> > >
> > > The Learning Robot
> > >
> > > Humans and machines, hand in hand.
> > >
> > > https://medium.com/apache-mxnet/the-learning-robot-1c2deab8f375
> > >
> > >
> > > Best
> > >
> > > Anton
> > >
> >
>

Re: The Learning Robot

[Carin Meier]

Great story!

I would love to retweet it on twitter. Is there anyway to get it out on the
https://twitter.com/ApacheMXNet account?

- Carin

On Fri, Mar 29, 2019 at 6:37 AM Anton Chernov  wrote:

> Dear MXNet Community,
>
>
> Read the development story of a robotics demo powered by deep learning with
> Apache MXNet on an embedded platform.
>
>
> The Learning Robot
>
> Humans and machines, hand in hand.
>
> https://medium.com/apache-mxnet/the-learning-robot-1c2deab8f375
>
>
> Best
>
> Anton
>

Re: MXNet Community Monthly Updates

[Carin Meier]

Mu,

Thanks for putting that together!

- Carin

On Mon, Mar 25, 2019 at 6:32 PM Mu Li  wrote:

> Great to see so many of yours like it.
>
> I create a template with some contents I'm familiar with. Need you help to
> put more cool staffs in. I have them in a google doc
> <
> https://docs.google.com/document/d/1AAy_EPdbEZqYvm6EfwgCzd6aEqcdH-v8tz2PYE6vMQ4/edit#heading=h.6zbltt894ho4
> >
> to
> ease to write together. (Maybe wiki is a better choice, I'm open to make a
> change).
>
> This report aims for a concise summary to existing mxnet users and, more
> importantly, attracting new users. So it's difference to Chaitanya's
> proposal focusing on MXNet activity summary, which should be very useful
> for MXNet developers.
>
> After we agreed on the contents, I'll coordinate to set up the email list
> and also publish on the channels suggested by Carin.
>
> Best
> Mu
>
> Draft link:
>
> https://docs.google.com/document/d/1AAy_EPdbEZqYvm6EfwgCzd6aEqcdH-v8tz2PYE6vMQ4/edit?usp=sharing
>
>
>
> On Fri, Mar 8, 2019 at 12:43 PM Carin Meier  wrote:
>
> > Other channels that might be beneficial for it to be published would be:
> >
> > - Twitter https://twitter.com/apachemxnet
> > - MXNet forum https://discuss.mxnet.io/
> > - MXNet Medium https://medium.com/apache-mxnet
> >
> > maybe even somewhere more general like Reddit Machine Learning
> > https://www.reddit.com/r/MachineLearning/ ?
> >
> > On Fri, Mar 8, 2019 at 10:50 AM Aaron Markham  >
> > wrote:
> >
> > > This is great. It will help drive traffic to the site, create content
> for
> > > the site, and increase engagement. MailChimp is pretty good too. I can
> > help
> > > set that up. I have one tiny nagging question though... I don't recall
> > > doing any GDPR compliance stuff on the site, so I'm wondering what kind
> > of
> > > EULA or popup thing we might need for the cookies and emails that come
> > > along with this feature. Did anyone get blessed with this task recently
> > and
> > > know what needs to be done?
> > >
> > > On Fri, Mar 8, 2019, 07:13 Carin Meier  wrote:
> > >
> > > > I strongly support this as well - Let us know when the wiki draft
> page
> > is
> > > > ready. The Clojure MXNet contributors have some cool stuff to share
> :)
> > > >
> > > > On Thu, Mar 7, 2019 at 1:49 AM Junru Shao 
> > > wrote:
> > > >
> > > > > Hi Mu,
> > > > >
> > > > > Thanks for proposing this! Strongly agree with the newsletter -
> this
> > > > would
> > > > > be the most economically efficient way to enhance community
> > > involvement.
> > > > >
> > > > > In addition to the draft wiki pages, should we send posts like
> "Call
> > > for
> > > > > newsletter articles" to dev@ list with some frequency? This could
> > help
> > > > > maximize the community awareness and help active community members
> > get
> > > > more
> > > > > exposure - Community building is important.
> > > > >
> > > > > Thanks,
> > > > > Junru
> > > > >
> > > > > On Wed, Mar 6, 2019 at 6:57 PM Chaitanya Bapat <
> chai.ba...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Hello Mu,
> > > > > >
> > > > > > Thanks a lot for bringing this topic. I had thought about a
> Weekly
> > > > Digest
> > > > > > for MXNet (weekly newsletter) - which is on similar lines (can be
> > > made
> > > > > into
> > > > > > Monthly if it sounds good).
> > > > > >
> > > > > > Here's the quip doc -
> > > > > > https://chaitanya.quip.com/BT6RAcAigHM9/MXNet-Weekly-Digest
> > > > > >
> > > > > > I have talked about the Background, Motivation, Features and a
> > mockup
> > > > of
> > > > > > Newsletter.
> > > > > >
> > > > > > Would love to hear our community's thoughts as well as yours on
> the
> > > > same.
> > > > > >
> > > > > > Please find attached a snapshot of the Weekly digest I came up
> > with.
> > > > > >
> > > > > > Thanks,
> > > > > > Chai
> > > > > >
> > > > > >
> > > > > >
> > &

[Announcement] New PPMC member - Qing Lan

[Carin Meier]

Please welcome Qing Lan (@lanking) as our newest PPMC member.

He has shown great leadership and community involvement with the Scala
package and JVM languages. We appreciate the work he has done to improve
the MXNet project in this way and make it friendly and open in the Apache
way.

Welcome!

- Carin

Re: MXNet Community Monthly Updates

[Carin Meier]

Other channels that might be beneficial for it to be published would be:

- Twitter https://twitter.com/apachemxnet
- MXNet forum https://discuss.mxnet.io/
- MXNet Medium https://medium.com/apache-mxnet

maybe even somewhere more general like Reddit Machine Learning
https://www.reddit.com/r/MachineLearning/ ?

On Fri, Mar 8, 2019 at 10:50 AM Aaron Markham 
wrote:

> This is great. It will help drive traffic to the site, create content for
> the site, and increase engagement. MailChimp is pretty good too. I can help
> set that up. I have one tiny nagging question though... I don't recall
> doing any GDPR compliance stuff on the site, so I'm wondering what kind of
> EULA or popup thing we might need for the cookies and emails that come
> along with this feature. Did anyone get blessed with this task recently and
> know what needs to be done?
>
> On Fri, Mar 8, 2019, 07:13 Carin Meier  wrote:
>
> > I strongly support this as well - Let us know when the wiki draft page is
> > ready. The Clojure MXNet contributors have some cool stuff to share :)
> >
> > On Thu, Mar 7, 2019 at 1:49 AM Junru Shao 
> wrote:
> >
> > > Hi Mu,
> > >
> > > Thanks for proposing this! Strongly agree with the newsletter - this
> > would
> > > be the most economically efficient way to enhance community
> involvement.
> > >
> > > In addition to the draft wiki pages, should we send posts like "Call
> for
> > > newsletter articles" to dev@ list with some frequency? This could help
> > > maximize the community awareness and help active community members get
> > more
> > > exposure - Community building is important.
> > >
> > > Thanks,
> > > Junru
> > >
> > > On Wed, Mar 6, 2019 at 6:57 PM Chaitanya Bapat 
> > > wrote:
> > >
> > > > Hello Mu,
> > > >
> > > > Thanks a lot for bringing this topic. I had thought about a Weekly
> > Digest
> > > > for MXNet (weekly newsletter) - which is on similar lines (can be
> made
> > > into
> > > > Monthly if it sounds good).
> > > >
> > > > Here's the quip doc -
> > > > https://chaitanya.quip.com/BT6RAcAigHM9/MXNet-Weekly-Digest
> > > >
> > > > I have talked about the Background, Motivation, Features and a mockup
> > of
> > > > Newsletter.
> > > >
> > > > Would love to hear our community's thoughts as well as yours on the
> > same.
> > > >
> > > > Please find attached a snapshot of the Weekly digest I came up with.
> > > >
> > > > Thanks,
> > > > Chai
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, 6 Mar 2019 at 19:59, Mu Li  wrote:
> > > >
> > > >> Dear Community,
> > > >>
> > > >> I propose to send a monthly summary to users to broadcast the recent
> > > >> progresses in the community. It will not only include new features
> > added
> > > >> into MXNet, but also various community activities. Here is an
> example:
> > > >>
> > > >> Tutorials
> > > >> - 10 new lectures teaching at UC Berkeley
> > > >> - Video record for "Deploying with Java" at Java World 19
> > > >> Computer Vision
> > > >> - GluonCV 0.4 release supports pose estimation and improves 10
> > existing
> > > >> models
> > > >> - Insightface added a new model XY
> > > >> NLP
> > > >> - GluonNLP 0.5.1 release improves BERT training
> > > >> New Projects
> > > >> - A MXNet implementation for paper XY
> > > >> MXNet
> > > >> - Enhanced Java binding preview
> > > >> - Numpy frontend reaches milestone 1
> > > >> Incoming Events
> > > >> - Meetup at Palto Alto on 4/2
> > > >>
> > > >> The publishing procedure is we first create a draft wiki page so
> > > everyone
> > > >> will have a chance to review and add staffs. After that we will send
> > it
> > > >> through an email list.
> > > >>
> > > >> I'm considering to use a 3rd party service such as mailchimp.com so
> > > that
> > > >> every user can subscribe it easily and we can do some marketing
> > analysis
> > > >> as
> > > >> well. But I'm happy to re-use us...@mxnet.apache.org if it provides
> > > >> simliar
> > > >> functionalities.
> > > >>
> > > >> I'd like to hear your feedback for how to make the newletter more
> user
> > > >> friendely.
> > > >>
> > > >> Best
> > > >> Mu
> > > >>
> > > >
> > > >
> > > > --
> > > > *Chaitanya Prakash Bapat*
> > > > *+1 (973) 953-6299*
> > > >
> > > > [image: https://www.linkedin.com//in/chaibapat25]
> > > > <https://github.com/ChaiBapchya>[image:
> > > > https://www.facebook.com/chaibapat] <
> > > https://www.facebook.com/chaibapchya>[image:
> > > > https://twitter.com/ChaiBapchya] <https://twitter.com/ChaiBapchya
> > > >[image:
> > > > https://www.linkedin.com//in/chaibapat25]
> > > > <https://www.linkedin.com//in/chaibapchya/>
> > > >
> > >
> >
>

Re: MXNet Community Monthly Updates

[Carin Meier]

I strongly support this as well - Let us know when the wiki draft page is
ready. The Clojure MXNet contributors have some cool stuff to share :)

On Thu, Mar 7, 2019 at 1:49 AM Junru Shao  wrote:

> Hi Mu,
>
> Thanks for proposing this! Strongly agree with the newsletter - this would
> be the most economically efficient way to enhance community involvement.
>
> In addition to the draft wiki pages, should we send posts like "Call for
> newsletter articles" to dev@ list with some frequency? This could help
> maximize the community awareness and help active community members get more
> exposure - Community building is important.
>
> Thanks,
> Junru
>
> On Wed, Mar 6, 2019 at 6:57 PM Chaitanya Bapat 
> wrote:
>
> > Hello Mu,
> >
> > Thanks a lot for bringing this topic. I had thought about a Weekly Digest
> > for MXNet (weekly newsletter) - which is on similar lines (can be made
> into
> > Monthly if it sounds good).
> >
> > Here's the quip doc -
> > https://chaitanya.quip.com/BT6RAcAigHM9/MXNet-Weekly-Digest
> >
> > I have talked about the Background, Motivation, Features and a mockup of
> > Newsletter.
> >
> > Would love to hear our community's thoughts as well as yours on the same.
> >
> > Please find attached a snapshot of the Weekly digest I came up with.
> >
> > Thanks,
> > Chai
> >
> >
> >
> >
> > On Wed, 6 Mar 2019 at 19:59, Mu Li  wrote:
> >
> >> Dear Community,
> >>
> >> I propose to send a monthly summary to users to broadcast the recent
> >> progresses in the community. It will not only include new features added
> >> into MXNet, but also various community activities. Here is an example:
> >>
> >> Tutorials
> >> - 10 new lectures teaching at UC Berkeley
> >> - Video record for "Deploying with Java" at Java World 19
> >> Computer Vision
> >> - GluonCV 0.4 release supports pose estimation and improves 10 existing
> >> models
> >> - Insightface added a new model XY
> >> NLP
> >> - GluonNLP 0.5.1 release improves BERT training
> >> New Projects
> >> - A MXNet implementation for paper XY
> >> MXNet
> >> - Enhanced Java binding preview
> >> - Numpy frontend reaches milestone 1
> >> Incoming Events
> >> - Meetup at Palto Alto on 4/2
> >>
> >> The publishing procedure is we first create a draft wiki page so
> everyone
> >> will have a chance to review and add staffs. After that we will send it
> >> through an email list.
> >>
> >> I'm considering to use a 3rd party service such as mailchimp.com so
> that
> >> every user can subscribe it easily and we can do some marketing analysis
> >> as
> >> well. But I'm happy to re-use us...@mxnet.apache.org if it provides
> >> simliar
> >> functionalities.
> >>
> >> I'd like to hear your feedback for how to make the newletter more user
> >> friendely.
> >>
> >> Best
> >> Mu
> >>
> >
> >
> > --
> > *Chaitanya Prakash Bapat*
> > *+1 (973) 953-6299*
> >
> > [image: https://www.linkedin.com//in/chaibapat25]
> > [image:
> > https://www.facebook.com/chaibapat] <
> https://www.facebook.com/chaibapchya>[image:
> > https://twitter.com/ChaiBapchya]  >[image:
> > https://www.linkedin.com//in/chaibapat25]
> > 
> >
>

Call for Ideas and Approaches to Community Building

[Carin Meier]

I wanted to kickoff a discussion about community building. There was an
excellent blog post from the Apache Beam Community on this
https://blogs.apache.org/comdev/entry/an-approach-to-community-building

In it they wanted to improve their contributor/committer base in the
following ways which resonate with our project as well, quoting from the
article:


1. We could use more committers to review all the code being contributed,
in part due to recent departure of a few committers

2. We want our contributor-base (hence committer-base) to be more spread
across companies and backgrounds. This is a core value of the Apache
Software Foundation. In particular, the project's direction should not be
dominated by any company, and the project should be able to survive the
departure of a major contributor or all contributors from a particular
employer. Eventually, we hope that our user base is active and diverse
enough that this happens naturally. But we are not there yet, so instead we
have to work hard to build our community around the software we already
have.



They outlined some of the steps that they took to achieve positive results
in the article, which I encourage everyone to read.

Every community is different, however, so things that worked well in their
community might not be as effective as in ours. I wanted to kick off a
discussion for ideas that people had here on community building for MXNet.

Ideas and thoughts on this are most welcome.

- Carin

Re: Help with the Clojure release jars

[Carin Meier]

The jars have been cleaned up. Thanks for the help everyone.

On Sun, Feb 24, 2019 at 7:27 PM Carin Meier  wrote:

> I also updated my instructions with big red letters not to do that again
> and documented how to fix it in a section at the bottom if for some reason
> it happens to the Clojure or Scala jars
> https://cwiki.apache.org/confluence/display/MXNET/Clojure+Release+Process.
>
>
> On Sun, Feb 24, 2019 at 7:18 PM Carin Meier  wrote:
>
>> Here is the link to the INFRA ticket
>> https://issues.apache.org/jira/browse/INFRA-17905
>> and the sonatype one https://issues.sonatype.org/browse/OSSRH-46500
>>
>> On Sun, Feb 24, 2019 at 6:52 PM Carin Meier  wrote:
>>
>>> Ok. I will open an INFRA ticket for it and keep this thread updated.
>>>
>>> On Sun, Feb 24, 2019 at 6:49 PM Naveen Swamy  wrote:
>>>
>>>> Since we release and vote on source and these were not a part of the
>>>> voting, I think it's ok do it independently I.e proceed with clean up
>>>> followed by rerelease so it won't impact closure users
>>>>
>>>> > On Feb 24, 2019, at 3:46 PM, Carin Meier 
>>>> wrote:
>>>> >
>>>> > Yes. It looks a bit confusing because I have a copy for the jars both
>>>> in
>>>> > staging and in releases since after I hit release, I created them
>>>> again
>>>> > while my brain was trying to figure out what went wrong.
>>>> >
>>>> > My understanding after talking with #asfinfra is that we would have
>>>> to:
>>>> > 1) Create an infra ticket to delete it from repository.apache.org
>>>> > 2) Create a ticket with issues.sonatype.org to delete it from central
>>>> >
>>>> > We can either
>>>> > -  Wait and let them be until the vote concludes, if the vote doesn't
>>>> pass
>>>> > I can make the tickets to delete them.
>>>> > - Create the tickets and delete them now.
>>>> >
>>>> > Let me know if this is what we want to do and I will kick off the
>>>> process.
>>>> >
>>>> > -Carin
>>>> >
>>>> >> On Sun, Feb 24, 2019 at 6:39 PM Naveen Swamy 
>>>> wrote:
>>>> >>
>>>> >> Did you close the repo? In my understanding, the repo(*.Apache.org)
>>>> is
>>>> >> under infra's control, so we porbably have to create a infra ticket,
>>>> last
>>>> >> time I wasn't able to delete( luckily it was in staging, so I
>>>> abandoned and
>>>> >> released to staging again.)
>>>> >>
>>>> >>> On Feb 24, 2019, at 2:36 PM, Carin Meier 
>>>> wrote:
>>>> >>>
>>>> >>> From the #infra channel, the options to fix seem to be that it can
>>>> be
>>>> >>> deleted from the repository.apache.org, but we'd need to talk to
>>>> >> sonatype
>>>> >>> about getting it removed.
>>>> >>>
>>>> >>> I'm not exactly sure where we are in the voting process for
>>>> release, so
>>>> >>> please let me know how everyone would like to proceed.
>>>> >>>
>>>> >>> Sorry again and I'll take steps to make sure that it won't happen
>>>> again.
>>>> >>>
>>>> >>> Best,
>>>> >>> Carin
>>>> >>>
>>>> >>>> On Sun, Feb 24, 2019 at 5:19 PM Carin Meier 
>>>> >> wrote:
>>>> >>>>
>>>> >>>> It appears I did accidentally release them :(
>>>> >>>>
>>>> >>>> I'm chatting with Infra in the slack room to see if there are any
>>>> fixes.
>>>> >>>> If anyone has any other ideas please let me know.
>>>> >>>>
>>>> >>>>> On Sun, Feb 24, 2019 at 4:35 PM Carin Meier >>> >
>>>> >> wrote:
>>>> >>>>>
>>>> >>>>> I was wondering if someone could help me verify if I accidentally
>>>> >>>>> released the Clojure jars.
>>>> >>>>>
>>>> >>>>> Background:
>>>> >>>>> I was creating and testing the Clojure jars for staging according
>>>> my my
>>>> >>>>> instructions[1].
>>>> >>>>> I hit the close button on the repository but I didn't see it
>>>> updated at
>>>> >>>>> the link
>>>> >>>>>
>>>> >>
>>>> https://repository.apache.org/content/repositories/staging/org/apache/mxnet/contrib/clojure/clojure-mxnet-linux-cpu/1.4.0/
>>>> >>>>> - so I hit the release button.
>>>> >>>>>
>>>> >>>>> Last time I did a release, I remember I had to explicitly hit the
>>>> >>>>> "promote" button to get it promoted to maven central at the
>>>> release
>>>> >> time,
>>>> >>>>> but now I'm not sure.
>>>> >>>>>
>>>> >>>>> So could someone please help me:
>>>> >>>>> 1) Figure out if I accidentally released it by mistake
>>>> >>>>> - there are 3 jars: The clojure linux-cpu, linux-gpu, and osx-cpu
>>>> >>>>> 2) If I did, please tell me how/if I can fix it (and sorry of
>>>> course)
>>>> >>>>> 3) Please let me know any corrections so I that I can update my
>>>> process
>>>> >>>>> instructions and make sure it doesn't happen again.
>>>> >>>>>
>>>> >>>>> Thanks,
>>>> >>>>> Carin
>>>> >>>>>
>>>> >>>>
>>>> >>
>>>>
>>>

Re: Help with the Clojure release jars

[Carin Meier]

I also updated my instructions with big red letters not to do that again
and documented how to fix it in a section at the bottom if for some reason
it happens to the Clojure or Scala jars
https://cwiki.apache.org/confluence/display/MXNET/Clojure+Release+Process.


On Sun, Feb 24, 2019 at 7:18 PM Carin Meier  wrote:

> Here is the link to the INFRA ticket
> https://issues.apache.org/jira/browse/INFRA-17905
> and the sonatype one https://issues.sonatype.org/browse/OSSRH-46500
>
> On Sun, Feb 24, 2019 at 6:52 PM Carin Meier  wrote:
>
>> Ok. I will open an INFRA ticket for it and keep this thread updated.
>>
>> On Sun, Feb 24, 2019 at 6:49 PM Naveen Swamy  wrote:
>>
>>> Since we release and vote on source and these were not a part of the
>>> voting, I think it's ok do it independently I.e proceed with clean up
>>> followed by rerelease so it won't impact closure users
>>>
>>> > On Feb 24, 2019, at 3:46 PM, Carin Meier  wrote:
>>> >
>>> > Yes. It looks a bit confusing because I have a copy for the jars both
>>> in
>>> > staging and in releases since after I hit release, I created them again
>>> > while my brain was trying to figure out what went wrong.
>>> >
>>> > My understanding after talking with #asfinfra is that we would have to:
>>> > 1) Create an infra ticket to delete it from repository.apache.org
>>> > 2) Create a ticket with issues.sonatype.org to delete it from central
>>> >
>>> > We can either
>>> > -  Wait and let them be until the vote concludes, if the vote doesn't
>>> pass
>>> > I can make the tickets to delete them.
>>> > - Create the tickets and delete them now.
>>> >
>>> > Let me know if this is what we want to do and I will kick off the
>>> process.
>>> >
>>> > -Carin
>>> >
>>> >> On Sun, Feb 24, 2019 at 6:39 PM Naveen Swamy 
>>> wrote:
>>> >>
>>> >> Did you close the repo? In my understanding, the repo(*.Apache.org) is
>>> >> under infra's control, so we porbably have to create a infra ticket,
>>> last
>>> >> time I wasn't able to delete( luckily it was in staging, so I
>>> abandoned and
>>> >> released to staging again.)
>>> >>
>>> >>> On Feb 24, 2019, at 2:36 PM, Carin Meier 
>>> wrote:
>>> >>>
>>> >>> From the #infra channel, the options to fix seem to be that it can be
>>> >>> deleted from the repository.apache.org, but we'd need to talk to
>>> >> sonatype
>>> >>> about getting it removed.
>>> >>>
>>> >>> I'm not exactly sure where we are in the voting process for release,
>>> so
>>> >>> please let me know how everyone would like to proceed.
>>> >>>
>>> >>> Sorry again and I'll take steps to make sure that it won't happen
>>> again.
>>> >>>
>>> >>> Best,
>>> >>> Carin
>>> >>>
>>> >>>> On Sun, Feb 24, 2019 at 5:19 PM Carin Meier 
>>> >> wrote:
>>> >>>>
>>> >>>> It appears I did accidentally release them :(
>>> >>>>
>>> >>>> I'm chatting with Infra in the slack room to see if there are any
>>> fixes.
>>> >>>> If anyone has any other ideas please let me know.
>>> >>>>
>>> >>>>> On Sun, Feb 24, 2019 at 4:35 PM Carin Meier 
>>> >> wrote:
>>> >>>>>
>>> >>>>> I was wondering if someone could help me verify if I accidentally
>>> >>>>> released the Clojure jars.
>>> >>>>>
>>> >>>>> Background:
>>> >>>>> I was creating and testing the Clojure jars for staging according
>>> my my
>>> >>>>> instructions[1].
>>> >>>>> I hit the close button on the repository but I didn't see it
>>> updated at
>>> >>>>> the link
>>> >>>>>
>>> >>
>>> https://repository.apache.org/content/repositories/staging/org/apache/mxnet/contrib/clojure/clojure-mxnet-linux-cpu/1.4.0/
>>> >>>>> - so I hit the release button.
>>> >>>>>
>>> >>>>> Last time I did a release, I remember I had to explicitly hit the
>>> >>>>> "promote" button to get it promoted to maven central at the release
>>> >> time,
>>> >>>>> but now I'm not sure.
>>> >>>>>
>>> >>>>> So could someone please help me:
>>> >>>>> 1) Figure out if I accidentally released it by mistake
>>> >>>>> - there are 3 jars: The clojure linux-cpu, linux-gpu, and osx-cpu
>>> >>>>> 2) If I did, please tell me how/if I can fix it (and sorry of
>>> course)
>>> >>>>> 3) Please let me know any corrections so I that I can update my
>>> process
>>> >>>>> instructions and make sure it doesn't happen again.
>>> >>>>>
>>> >>>>> Thanks,
>>> >>>>> Carin
>>> >>>>>
>>> >>>>
>>> >>
>>>
>>

Re: Help with the Clojure release jars

[Carin Meier]

Here is the link to the INFRA ticket
https://issues.apache.org/jira/browse/INFRA-17905
and the sonatype one https://issues.sonatype.org/browse/OSSRH-46500

On Sun, Feb 24, 2019 at 6:52 PM Carin Meier  wrote:

> Ok. I will open an INFRA ticket for it and keep this thread updated.
>
> On Sun, Feb 24, 2019 at 6:49 PM Naveen Swamy  wrote:
>
>> Since we release and vote on source and these were not a part of the
>> voting, I think it's ok do it independently I.e proceed with clean up
>> followed by rerelease so it won't impact closure users
>>
>> > On Feb 24, 2019, at 3:46 PM, Carin Meier  wrote:
>> >
>> > Yes. It looks a bit confusing because I have a copy for the jars both in
>> > staging and in releases since after I hit release, I created them again
>> > while my brain was trying to figure out what went wrong.
>> >
>> > My understanding after talking with #asfinfra is that we would have to:
>> > 1) Create an infra ticket to delete it from repository.apache.org
>> > 2) Create a ticket with issues.sonatype.org to delete it from central
>> >
>> > We can either
>> > -  Wait and let them be until the vote concludes, if the vote doesn't
>> pass
>> > I can make the tickets to delete them.
>> > - Create the tickets and delete them now.
>> >
>> > Let me know if this is what we want to do and I will kick off the
>> process.
>> >
>> > -Carin
>> >
>> >> On Sun, Feb 24, 2019 at 6:39 PM Naveen Swamy 
>> wrote:
>> >>
>> >> Did you close the repo? In my understanding, the repo(*.Apache.org) is
>> >> under infra's control, so we porbably have to create a infra ticket,
>> last
>> >> time I wasn't able to delete( luckily it was in staging, so I
>> abandoned and
>> >> released to staging again.)
>> >>
>> >>> On Feb 24, 2019, at 2:36 PM, Carin Meier 
>> wrote:
>> >>>
>> >>> From the #infra channel, the options to fix seem to be that it can be
>> >>> deleted from the repository.apache.org, but we'd need to talk to
>> >> sonatype
>> >>> about getting it removed.
>> >>>
>> >>> I'm not exactly sure where we are in the voting process for release,
>> so
>> >>> please let me know how everyone would like to proceed.
>> >>>
>> >>> Sorry again and I'll take steps to make sure that it won't happen
>> again.
>> >>>
>> >>> Best,
>> >>> Carin
>> >>>
>> >>>> On Sun, Feb 24, 2019 at 5:19 PM Carin Meier 
>> >> wrote:
>> >>>>
>> >>>> It appears I did accidentally release them :(
>> >>>>
>> >>>> I'm chatting with Infra in the slack room to see if there are any
>> fixes.
>> >>>> If anyone has any other ideas please let me know.
>> >>>>
>> >>>>> On Sun, Feb 24, 2019 at 4:35 PM Carin Meier 
>> >> wrote:
>> >>>>>
>> >>>>> I was wondering if someone could help me verify if I accidentally
>> >>>>> released the Clojure jars.
>> >>>>>
>> >>>>> Background:
>> >>>>> I was creating and testing the Clojure jars for staging according
>> my my
>> >>>>> instructions[1].
>> >>>>> I hit the close button on the repository but I didn't see it
>> updated at
>> >>>>> the link
>> >>>>>
>> >>
>> https://repository.apache.org/content/repositories/staging/org/apache/mxnet/contrib/clojure/clojure-mxnet-linux-cpu/1.4.0/
>> >>>>> - so I hit the release button.
>> >>>>>
>> >>>>> Last time I did a release, I remember I had to explicitly hit the
>> >>>>> "promote" button to get it promoted to maven central at the release
>> >> time,
>> >>>>> but now I'm not sure.
>> >>>>>
>> >>>>> So could someone please help me:
>> >>>>> 1) Figure out if I accidentally released it by mistake
>> >>>>> - there are 3 jars: The clojure linux-cpu, linux-gpu, and osx-cpu
>> >>>>> 2) If I did, please tell me how/if I can fix it (and sorry of
>> course)
>> >>>>> 3) Please let me know any corrections so I that I can update my
>> process
>> >>>>> instructions and make sure it doesn't happen again.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Carin
>> >>>>>
>> >>>>
>> >>
>>
>

Re: Help with the Clojure release jars

[Carin Meier]

Ok. I will open an INFRA ticket for it and keep this thread updated.

On Sun, Feb 24, 2019 at 6:49 PM Naveen Swamy  wrote:

> Since we release and vote on source and these were not a part of the
> voting, I think it's ok do it independently I.e proceed with clean up
> followed by rerelease so it won't impact closure users
>
> > On Feb 24, 2019, at 3:46 PM, Carin Meier  wrote:
> >
> > Yes. It looks a bit confusing because I have a copy for the jars both in
> > staging and in releases since after I hit release, I created them again
> > while my brain was trying to figure out what went wrong.
> >
> > My understanding after talking with #asfinfra is that we would have to:
> > 1) Create an infra ticket to delete it from repository.apache.org
> > 2) Create a ticket with issues.sonatype.org to delete it from central
> >
> > We can either
> > -  Wait and let them be until the vote concludes, if the vote doesn't
> pass
> > I can make the tickets to delete them.
> > - Create the tickets and delete them now.
> >
> > Let me know if this is what we want to do and I will kick off the
> process.
> >
> > -Carin
> >
> >> On Sun, Feb 24, 2019 at 6:39 PM Naveen Swamy 
> wrote:
> >>
> >> Did you close the repo? In my understanding, the repo(*.Apache.org) is
> >> under infra's control, so we porbably have to create a infra ticket,
> last
> >> time I wasn't able to delete( luckily it was in staging, so I abandoned
> and
> >> released to staging again.)
> >>
> >>> On Feb 24, 2019, at 2:36 PM, Carin Meier  wrote:
> >>>
> >>> From the #infra channel, the options to fix seem to be that it can be
> >>> deleted from the repository.apache.org, but we'd need to talk to
> >> sonatype
> >>> about getting it removed.
> >>>
> >>> I'm not exactly sure where we are in the voting process for release, so
> >>> please let me know how everyone would like to proceed.
> >>>
> >>> Sorry again and I'll take steps to make sure that it won't happen
> again.
> >>>
> >>> Best,
> >>> Carin
> >>>
> >>>> On Sun, Feb 24, 2019 at 5:19 PM Carin Meier 
> >> wrote:
> >>>>
> >>>> It appears I did accidentally release them :(
> >>>>
> >>>> I'm chatting with Infra in the slack room to see if there are any
> fixes.
> >>>> If anyone has any other ideas please let me know.
> >>>>
> >>>>> On Sun, Feb 24, 2019 at 4:35 PM Carin Meier 
> >> wrote:
> >>>>>
> >>>>> I was wondering if someone could help me verify if I accidentally
> >>>>> released the Clojure jars.
> >>>>>
> >>>>> Background:
> >>>>> I was creating and testing the Clojure jars for staging according my
> my
> >>>>> instructions[1].
> >>>>> I hit the close button on the repository but I didn't see it updated
> at
> >>>>> the link
> >>>>>
> >>
> https://repository.apache.org/content/repositories/staging/org/apache/mxnet/contrib/clojure/clojure-mxnet-linux-cpu/1.4.0/
> >>>>> - so I hit the release button.
> >>>>>
> >>>>> Last time I did a release, I remember I had to explicitly hit the
> >>>>> "promote" button to get it promoted to maven central at the release
> >> time,
> >>>>> but now I'm not sure.
> >>>>>
> >>>>> So could someone please help me:
> >>>>> 1) Figure out if I accidentally released it by mistake
> >>>>> - there are 3 jars: The clojure linux-cpu, linux-gpu, and osx-cpu
> >>>>> 2) If I did, please tell me how/if I can fix it (and sorry of course)
> >>>>> 3) Please let me know any corrections so I that I can update my
> process
> >>>>> instructions and make sure it doesn't happen again.
> >>>>>
> >>>>> Thanks,
> >>>>> Carin
> >>>>>
> >>>>
> >>
>

Re: Help with the Clojure release jars

[Carin Meier]

Yes. It looks a bit confusing because I have a copy for the jars both in
staging and in releases since after I hit release, I created them again
while my brain was trying to figure out what went wrong.

My understanding after talking with #asfinfra is that we would have to:
1) Create an infra ticket to delete it from repository.apache.org
2) Create a ticket with issues.sonatype.org to delete it from central

We can either
 -  Wait and let them be until the vote concludes, if the vote doesn't pass
I can make the tickets to delete them.
 - Create the tickets and delete them now.

Let me know if this is what we want to do and I will kick off the process.

 -Carin

On Sun, Feb 24, 2019 at 6:39 PM Naveen Swamy  wrote:

> Did you close the repo? In my understanding, the repo(*.Apache.org) is
> under infra's control, so we porbably have to create a infra ticket, last
> time I wasn't able to delete( luckily it was in staging, so I abandoned and
> released to staging again.)
>
> > On Feb 24, 2019, at 2:36 PM, Carin Meier  wrote:
> >
> > From the #infra channel, the options to fix seem to be that it can be
> > deleted from the repository.apache.org, but we'd need to talk to
> sonatype
> > about getting it removed.
> >
> > I'm not exactly sure where we are in the voting process for release, so
> > please let me know how everyone would like to proceed.
> >
> > Sorry again and I'll take steps to make sure that it won't happen again.
> >
> > Best,
> > Carin
> >
> >> On Sun, Feb 24, 2019 at 5:19 PM Carin Meier 
> wrote:
> >>
> >> It appears I did accidentally release them :(
> >>
> >> I'm chatting with Infra in the slack room to see if there are any fixes.
> >> If anyone has any other ideas please let me know.
> >>
> >>> On Sun, Feb 24, 2019 at 4:35 PM Carin Meier 
> wrote:
> >>>
> >>> I was wondering if someone could help me verify if I accidentally
> >>> released the Clojure jars.
> >>>
> >>> Background:
> >>> I was creating and testing the Clojure jars for staging according my my
> >>> instructions[1].
> >>> I hit the close button on the repository but I didn't see it updated at
> >>> the link
> >>>
> https://repository.apache.org/content/repositories/staging/org/apache/mxnet/contrib/clojure/clojure-mxnet-linux-cpu/1.4.0/
> >>> - so I hit the release button.
> >>>
> >>> Last time I did a release, I remember I had to explicitly hit the
> >>> "promote" button to get it promoted to maven central at the release
> time,
> >>> but now I'm not sure.
> >>>
> >>> So could someone please help me:
> >>> 1) Figure out if I accidentally released it by mistake
> >>>  - there are 3 jars: The clojure linux-cpu, linux-gpu, and osx-cpu
> >>> 2) If I did, please tell me how/if I can fix it (and sorry of course)
> >>> 3) Please let me know any corrections so I that I can update my process
> >>> instructions and make sure it doesn't happen again.
> >>>
> >>> Thanks,
> >>> Carin
> >>>
> >>
>

Re: Help with the Clojure release jars

[Carin Meier]

>From the #infra channel, the options to fix seem to be that it can be
deleted from the repository.apache.org, but we'd need to talk to sonatype
about getting it removed.

I'm not exactly sure where we are in the voting process for release, so
please let me know how everyone would like to proceed.

Sorry again and I'll take steps to make sure that it won't happen again.

Best,
Carin

On Sun, Feb 24, 2019 at 5:19 PM Carin Meier  wrote:

> It appears I did accidentally release them :(
>
> I'm chatting with Infra in the slack room to see if there are any fixes.
> If anyone has any other ideas please let me know.
>
> On Sun, Feb 24, 2019 at 4:35 PM Carin Meier  wrote:
>
>> I was wondering if someone could help me verify if I accidentally
>> released the Clojure jars.
>>
>> Background:
>> I was creating and testing the Clojure jars for staging according my my
>> instructions[1].
>> I hit the close button on the repository but I didn't see it updated at
>> the link
>> https://repository.apache.org/content/repositories/staging/org/apache/mxnet/contrib/clojure/clojure-mxnet-linux-cpu/1.4.0/
>> - so I hit the release button.
>>
>> Last time I did a release, I remember I had to explicitly hit the
>> "promote" button to get it promoted to maven central at the release time,
>> but now I'm not sure.
>>
>> So could someone please help me:
>> 1) Figure out if I accidentally released it by mistake
>>   - there are 3 jars: The clojure linux-cpu, linux-gpu, and osx-cpu
>> 2) If I did, please tell me how/if I can fix it (and sorry of course)
>> 3) Please let me know any corrections so I that I can update my process
>> instructions and make sure it doesn't happen again.
>>
>> Thanks,
>> Carin
>>
>

Re: Help with the Clojure release jars

[Carin Meier]

It appears I did accidentally release them :(

I'm chatting with Infra in the slack room to see if there are any fixes. If
anyone has any other ideas please let me know.

On Sun, Feb 24, 2019 at 4:35 PM Carin Meier  wrote:

> I was wondering if someone could help me verify if I accidentally released
> the Clojure jars.
>
> Background:
> I was creating and testing the Clojure jars for staging according my my
> instructions[1].
> I hit the close button on the repository but I didn't see it updated at
> the link
> https://repository.apache.org/content/repositories/staging/org/apache/mxnet/contrib/clojure/clojure-mxnet-linux-cpu/1.4.0/
> - so I hit the release button.
>
> Last time I did a release, I remember I had to explicitly hit the
> "promote" button to get it promoted to maven central at the release time,
> but now I'm not sure.
>
> So could someone please help me:
> 1) Figure out if I accidentally released it by mistake
>   - there are 3 jars: The clojure linux-cpu, linux-gpu, and osx-cpu
> 2) If I did, please tell me how/if I can fix it (and sorry of course)
> 3) Please let me know any corrections so I that I can update my process
> instructions and make sure it doesn't happen again.
>
> Thanks,
> Carin
>

Help with the Clojure release jars

[Carin Meier]

I was wondering if someone could help me verify if I accidentally released
the Clojure jars.

Background:
I was creating and testing the Clojure jars for staging according my my
instructions[1].
I hit the close button on the repository but I didn't see it updated at the
link
https://repository.apache.org/content/repositories/staging/org/apache/mxnet/contrib/clojure/clojure-mxnet-linux-cpu/1.4.0/
- so I hit the release button.

Last time I did a release, I remember I had to explicitly hit the "promote"
button to get it promoted to maven central at the release time, but now I'm
not sure.

So could someone please help me:
1) Figure out if I accidentally released it by mistake
  - there are 3 jars: The clojure linux-cpu, linux-gpu, and osx-cpu
2) If I did, please tell me how/if I can fix it (and sorry of course)
3) Please let me know any corrections so I that I can update my process
instructions and make sure it doesn't happen again.

Thanks,
Carin

Re: Wiki Access for Kedar Bellare

[Carin Meier]

Thank you!

On Sun, Feb 24, 2019 at 1:51 PM Naveen Swamy  wrote:

> i added kedar, i updated your id to have admin access.
>
> On Sun, Feb 24, 2019 at 10:43 AM Carin Meier  wrote:
>
> > Can someone please help Kedar get write access to our wiki? I don't have
> > that access. He is taking the lead on the next generation of our Clojure
> > package NDArray and Symbol APIs [1] and would like to collaborate on some
> > design documentation.
> >
> > Thanks!
> > Carin
> >
> > [1] https://github.com/apache/incubator-mxnet/pull/14195
> >
>

Wiki Access for Kedar Bellare

[Carin Meier]

Can someone please help Kedar get write access to our wiki? I don't have
that access. He is taking the lead on the next generation of our Clojure
package NDArray and Symbol APIs [1] and would like to collaborate on some
design documentation.

Thanks!
Carin

[1] https://github.com/apache/incubator-mxnet/pull/14195

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc3

[Carin Meier]

+1 Downloaded and verified the signature on the tar. Built and tested the
Scala/Clojure package

On Sun, Feb 17, 2019 at 2:13 PM Qing Lan  wrote:

> +1 (binding) on the release. Checked Mac + Linux (Ubuntu 16.04) build from
> source successfully. Checked Scala build with no errors.
>
> On 2/15/19, 6:08 PM, "Piyush Ghai"  wrote:
>
> Dear MXNet community,
>
> I would like to propose a vote to release Apache MXNet (incubating)
> version v1.4.0.
> Voting will start today, Friday February 15th 6pm PST and will close
> on Monday,
> February 18th 6pm PST.
>
> Link to release notes:
>
>
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.0+Release+Notes
> <
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+(incubating)+1.4.0+Release+Notes
> >
>
> Link to release candidate 1.4.0.rc3:
>  
> https://github.com/apache/incubator-mxnet/releases/tag/1.4.0.rc3 <
> https://github.com/apache/incubator-mxnet/releases/tag/1.4.0.rc3>/
>
> Link to source and signatures on apache dist server:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.0.rc3/ <
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.0.rc3/>
>
>
> Please remember to TEST first before voting accordingly:
> +1 = approve
> +0 = no opinion
> -1 = disapprove (provide reason)
>
>
> Best regards,
> Piyush
>
>

[Announcement] New Committer - Nicolas Modrzyk

[Carin Meier]

Please join me in welcoming Nicolas Modrzyk, (@hellonico), as a new
committer.

He has made valuable contributions to the Clojure package, especially in
the areas of stability with integration tests and visualizations [1].

We are excited to have him with us as a committer and look forward to
future growth of the MXNet Clojure package and community.

- Carin


[1]
https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+hellonico+

Re: Question about Gluon Api for Scala package & JVM langs

[Carin Meier]

I started a proposal page on it
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103089990

It is a big chunk of work and needs some serious analysis - but it's a
starting point for a conversation :)

On Tue, Jan 22, 2019 at 1:56 PM Carin Meier  wrote:

> Thanks!
>
> I've heard this from our Clojure community so if anyone else would like to
> chime in, please feel free...
>
> One popular Deep Learning book out there is "Dive into Deep Learning"
> https://d2l.ai/ -  which has its examples in Gluon. It would be nice as a
> starting point in the discussion to see what is covered in there and the
> scope/effort it would be to build it out.
>
> I'll help draft a proposal in the next few days.
>
> - Carin
>
> On Tue, Jan 22, 2019 at 1:32 PM Qing Lan  wrote:
>
>> Hi Carin,
>>
>> Thanks for your question. I would like to know which part(s) of Gluon you
>> would like to see for JVM in general?
>> Since itself if big, we can start working on the components users needed
>> the most and then cover the rest of the part.
>> Please feel free to draft a proposal somewhere and we can discuss about
>> it.
>>
>> Thanks,
>> Qing
>>
>> On 1/21/19, 4:53 PM, "Carin Meier"  wrote:
>>
>> Currently the Scala package supports the Module and FeedForward APIs.
>> Since
>> quite a bit of the documentation is focusing now on the Gluon API, I
>> wondered if there were thoughts of bringing the Gluon interface to the
>> Scala package in the future for the JVM langs.
>>
>> - Carin
>>
>>
>>

Re: Third-party package tests for MXNet nightly builds

[Carin Meier]

Can't speak for the CI team, but in general I think that it is good idea.

On a separate note, I've been playing around with Sockeye recently and it's
great! Awesome work and glad to see MXNet used for such cutting edge use
cases.
I'd love to see closer collaboration with the Sockeye team and MXNet for
innovation, cross pollination, and evangelization of what MXNet can do .

Best,
Carin

On Mon, Feb 11, 2019 at 6:01 AM Felix Hieber  wrote:

> Hello dev@,
>
>
>
> I would like to ask around whether there is interest in the community to
> test nightly builds of MXNet with third-party packages that depend on MXNet
> and act as early adopters. The goal is to catch regressions in MXNet early,
> allowing time for bug fixes before a new release is cut.
>
>
>
> For example, Sockeye  is a customer of
> new MXNet releases and aims to upgrade to latest MXNet as soon as possible.
> Typically, we update our dependency on MXNet once a new release becomes
> available (through pip). However, there have been cases where new releases
> of MXNet introduced regressions undetected by MXNet tests (hence passing
> the release process): the latest example is this issue
> , which may have
> been introduced already back in October, but, due to infrequent MXNet
> releases, has only surfaced recently and will most likely force us to wait
> for a post or 1.4.1 release. In this particular example, Sockeye’s tests
> would have detected this, and the issue could have been created already in
> October, potentially avoiding its presence in the 1.4.0 release.
>
>
>
> More generally, I think there are several third-party packages with
> valuable test suites (e.g. gluon-nlp) that can contribute to catching MXNet
> regressions or incompatibilities early. Running these test suites for each
> and every PR or commit on the MXNet main repo would be too much overhead.
> My proposal would be to trigger these tests with the nightly builds (pip
> releases) of MXNet in a separate CI pipeline that is able to notify the 3p
> maintainers in a case of failure, but does not block MXNet development (or
> nightly build releases) in any way.
>
> Roughly it would do the following:
>
>- pip install mxnet--
>- for each 3p package that is part of the pipeline:
>   - clone/setup up package
>   - run unit/integration tests of package with some timeout
>   - in case of failure, notify package owner
>
>
>
> I am not familiar with the current CI pipelines, their requirements and
> resources. It would be great if someone from the CI team could chime in and
> evaluate whether such a proposal seems doable and worthwhile.
>
>
>
> Best,
>
> Felix
>

Re: First class support for MxNet?

[Carin Meier]

+100 on Iblis's thoughts:

"We know tools and frameworks keep changing.
People learn the lesson from making and attempting.
It's just the path of the human technology evolution.
The point is the ideas/experiences
which this community is going to surprise you at."

- Carin


On Mon, Feb 11, 2019 at 9:08 AM iblis  wrote:

> well, I'm not going to talk about technical stuffs.
> You can find some design concepts on doc or wiki.
> (
> https://mxnet.incubator.apache.org/versions/master/architecture/index.html
> )
>
> For me, working on MXNet is a rare chance to verify my ideas of
> a machine learning framework.
> During implementing MXNet Julia package, I can explicitly compare the
> experience of MXNet with Flux's
> ...and than start to complaining about them. :p
> I think a way to moving forward is comparison.
> So that's why I said I want to increase the diversity of DL tools in Julia.
>
> I like the spirit of portability in MXNet community.
> We welcomed all of language packages and open-minded.
> Although some of languages might be considered not popular in ML/DL,
> this community still keep polishing them day in day out.
> Yeah, someone has to try it, compare and gain experience from this
> process regardless of how the language has been evaluated in ML.
> The experience is valuable.
> (e.g. I think lack of function overloading is a disadvantage
>   of Python; the file-based namespace does help for maintainability
>   in Python.
>   After I did some works in Julia, I can clearly point out pros and cons.)
>
>  From a long-term view... maybe twenty years after,
> none of the languages we are using now will be popular.
> But I believe the meta-rules which extracted from experiences are still
> applied.
>
> So.. why not have a Rust lib? maybe Rust's macro can do something crazy,
> maybe.
> e.g. Julia package shows a more elegant way to stack a network than Python,
> thanks to metaprogramming.
>
>mlp = @mx.chain mx.Variable(:data) =>
>  mx.FullyConnected(name=:fc1, num_hidden=128) =>
>  mx.Activation(name=:relu1, act_type=:relu)   =>
>  mx.FullyConnected(name=:fc2, num_hidden=64)  =>
>  mx.Activation(name=:relu2, act_type=:relu)   =>
>  mx.FullyConnected(name=:fc3, num_hidden=10)  =>
>  mx.SoftmaxOutput(name=:softmax)
>
>
> > Wondering where that leaves MxNet...
>
> Actually, I don't case about this issue.
> We know tools and frameworks keep changing.
> People learn the lesson from making and attempting.
> It's just the path of the human technology evolution.
> The point is the ideas/experiences
> which this community is going to surprise you at.
>
>
> Iblis Lin
> 林峻頤
>
> On 2/11/19 12:04 PM, Zach Boldyga wrote:
> > Those are compelling points! There's also another more recent follow-up
> > from the Julia team:
> https://julialang.org/blog/2018/12/ml-language-compiler
> > .
> >
> > It seems that Julia will likely have it's place in ML regardless of how
> > other tools progress; the latest offerings from Julia/Flux are really
> > compelling.
> >
> > Wondering where that leaves MxNet...
> >
> > Zach Boldyga
> > Scalabull  |  Founder
> > 1 (866) 846-8771 x 101
> >
>

Re: [Announcement] New Committer -- Steffen Rochel

[Carin Meier]

Congrats and welcome!

On Wed, Feb 6, 2019 at 9:13 AM Pedro Larroy 
wrote:

> Congrats Steffen.
>
> On Tue, Feb 5, 2019 at 7:48 PM Yuan Tang  wrote:
> >
> > Welcome!
> >
> > On Tue, Feb 5, 2019 at 1:46 PM Gavin M. Bell 
> > wrote:
> >
> > > Great news!
> > >
> > >
> > > On Tue, Feb 5, 2019 at 6:16 PM Lin Yuan  wrote:
> > >
> > > > Welcome Steffen!
> > > >
> > > > Lin
> > > >
> > > > On Mon, Feb 4, 2019 at 7:53 PM kellen sunderland <
> > > > kellen.sunderl...@gmail.com> wrote:
> > > >
> > > > > Great news.  Congrats Steffen.
> > > > >
> > > > > On Mon, Feb 4, 2019, 5:29 PM Thomas DELTEIL <
> thomas.delte...@gmail.com
> > > > > wrote:
> > > > >
> > > > > > Welcome Steffen!
> > > > > >
> > > > > > On Mon, Feb 4, 2019, 15:55 Marco de Abreu <
> marco.g.ab...@gmail.com
> > > > > wrote:
> > > > > >
> > > > > > > Welcome!
> > > > > > >
> > > > > > > Am Di., 5. Feb. 2019, 00:45 hat Chris Olivier <
> > > > cjolivie...@apache.org>
> > > > > > > geschrieben:
> > > > > > >
> > > > > > > > Dear Community:
> > > > > > > >
> > > > > > > > Please join me to welcome Steffen Rochel (
> > > steffenroc...@gmail.com)
> > > > > as
> > > > > > a
> > > > > > > > new
> > > > > > > > committer of Apache (incubating) MXNet!
> > > > > > > >
> > > > > > > > Steffen has played a role in nearly every MXNet release in
> the
> > > past
> > > > > 18
> > > > > > > > months, managed several of the wiki pages and has
> contributed in
> > > > > > > expanding
> > > > > > > > the community by managing and hosting meetups in different
> parts
> > > of
> > > > > the
> > > > > > > > world.
> > > > > > > >
> > > > > > > > -Chris
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Sincerely,
> > > Gavin M. Bell
> > >
> > >  "Never mistake a clear view for a short distance."
> > >   -Paul Saffo
> > >
>

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc2

[Carin Meier]

+1 - checked out from the release tag and built and tested Scala/Clojure
package.

On Sat, Jan 26, 2019 at 8:53 PM Steffen Rochel 
wrote:

> Dear MXNet community,
>
> This is the vote to release Apache MXNet (incubating) version v1.4.0.
> Voting will
> start today, Saturday January 26th 6pm PST and will close on Wednesday,
> January 30th 7pm PST.
>
> Link to release notes:
>
>
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+
> 1.4.0+Release+Notes
>
> Link to release candidate:
> https://github.com/apache/incubator-mxnet/releases/tag/
> 1.4.0.rc
> 2
>
> Link to source and signatures on apache dist server:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.0.rc2
>
>
> Please remember to TEST first before voting accordingly:
> +1 = approve
> +0 = no opinion
> -1 = disapprove (provide reason)
>
>
> Best regards,
> Steffen
>
> >
>

Re: Rust Client Lib

[Carin Meier]

Hi Zach,

I'm the original author of the Clojure package so I can give you my
perspective, (although your path might be different).

First, one of the advantages that MXNet has of the other deep learning
libraries is its multi-language support. People can program and develop in
the language of their choice.

The path the Clojure package took is that it originated in an github issue.
>From there, the main package was developed in my personal repo until it got
to a point that I could share it and get feedback from other people in the
Clojure community. Once I felt like it was developed enough, I sent out a
email to the dev list, opened a PR, and drafted up some documentation on
the Design and Architecture as well as the state of things on the wiki
https://cwiki.apache.org/confluence/display/MXNET/MXNet+Clojure.

After much feedback and review, it was brought in under as a "contrib"
package, where it is spending time stabilizing and generally improving to
the point that it can "graduate".

It's a long term commitment to bring a new language support in, but it is
very rewarding for both the MXNet project and your language community.

One valuable piece of feedback that I got on the original PR
https://github.com/apache/incubator-mxnet/pull/11205 that might be valuable
for you as well to think of, came from Kovas Boguta on higher level
concerns:

- What will the debug experience be like? How do users track down errors
that happen in the front end Rust code or lower level code?
- What does maintenance look like? How does the Rust API evolve with the
rest of the library?
- How do people learn to use this thing? Is there any easy way to go from
the current MXNet docs to the Rust version. How is the documentation going
to work long term.

I hope this helps,
Carin




On Tue, Jan 29, 2019 at 5:05 AM Zach Boldyga  wrote:

> Hey y'all!
>
> I'm thinking about spending this week working on a rust client lib for
> MXNet. saw a little bit of chatter about this in the github issues and no
> strong existing crates at the moment. Any pointers on approaching this in a
> way that will lead to it being adopted as an officially supported client
> library? And overall yay/nay on whether adding a Rust lib makes sense & why
> / why not?
>
> Zach Boldyga
> Scalabull  |  Founder
> 1 (866) 846-8771 x 101
>

[ANNOUNCE] - Integration tests for the Clojure Package

[Carin Meier]

I'd like to announce the introduction of CI integration tests for the
Clojure package. This is a big win for stability and maturity thanks to the
efforts of contributor Nicolas Modrzyk, (@hellonico).
https://github.com/apache/incubator-mxnet/pull/13624

Also thanks to Marco and Pedro thanks for your input and feedback to make
this possible.

- Thanks

Re: Question about Gluon Api for Scala package & JVM langs

[Carin Meier]

Thanks!

I've heard this from our Clojure community so if anyone else would like to
chime in, please feel free...

One popular Deep Learning book out there is "Dive into Deep Learning"
https://d2l.ai/ -  which has its examples in Gluon. It would be nice as a
starting point in the discussion to see what is covered in there and the
scope/effort it would be to build it out.

I'll help draft a proposal in the next few days.

- Carin

On Tue, Jan 22, 2019 at 1:32 PM Qing Lan  wrote:

> Hi Carin,
>
> Thanks for your question. I would like to know which part(s) of Gluon you
> would like to see for JVM in general?
> Since itself if big, we can start working on the components users needed
> the most and then cover the rest of the part.
> Please feel free to draft a proposal somewhere and we can discuss about it.
>
> Thanks,
> Qing
>
> On 1/21/19, 4:53 PM, "Carin Meier"  wrote:
>
> Currently the Scala package supports the Module and FeedForward APIs.
> Since
> quite a bit of the documentation is focusing now on the Gluon API, I
> wondered if there were thoughts of bringing the Gluon interface to the
> Scala package in the future for the JVM langs.
>
> - Carin
>
>
>

Question about Gluon Api for Scala package & JVM langs

[Carin Meier]

Currently the Scala package supports the Module and FeedForward APIs. Since
quite a bit of the documentation is focusing now on the Gluon API, I
wondered if there were thoughts of bringing the Gluon interface to the
Scala package in the future for the JVM langs.

- Carin

Re: [Article] Object Detection with Clojure MXNet

[Carin Meier]

Thanks - props for the images belongs to the original Scala article
https://medium.com/apache-mxnet/object-detection-with-mxnet-scala-inference-api-9049230c77fd
and Kedar - the contributor that ported the object detection feature to
Clojure. They are pretty awesome though.



On Sat, Jan 19, 2019 at 4:57 PM Marco de Abreu 
wrote:

> Great article! I have to admit I always love your picture choices :D
>
> -Marco
>
> Am Sa., 19. Jan. 2019, 21:57 hat Carin Meier 
> geschrieben:
>
> > I just blogged about the new Object Detection feature that was just
> ported
> > from the Scala package into the Clojure package.
> >
> >
> http://gigasquidsoftware.com/blog/2019/01/19/object-detection-with-clojure-mxnet/
> >
> > I posted it in Slack but in an effort to direct more communication
> towards
> > this mailing list, I'm putting it out here too :)
> >
> > - Carin
> >
>

[Article] Object Detection with Clojure MXNet

[Carin Meier]

I just blogged about the new Object Detection feature that was just ported
from the Scala package into the Clojure package.
http://gigasquidsoftware.com/blog/2019/01/19/object-detection-with-clojure-mxnet/

I posted it in Slack but in an effort to direct more communication towards
this mailing list, I'm putting it out here too :)

- Carin

Re: [ANNOUNCE] Jenkins Nightly Release Pipeline with MXNet Scala

[Carin Meier]

Thanks for everyone involved in this effort. This not only is a huge win
for the Scala community but also for the Clojure community which depends on
the Scala jar artifact.

Well done.

On Fri, Jan 18, 2019 at 9:58 PM Zach Kimberg 
wrote:

> Hi,
>
> A little over a month ago, we announced the nightly build of the Scala
> package on Nexus [1]. It featured the same statically linked binary build
> logic used by the Python pip to make the adoption as easy for our JVM users
> as for our python users. However, that release occurred on a private
> pipeline using code that was not publicly available.
>
> First, I would like to thank Sheng for contributing the pip binary build
> scripts to the community and making them accessible as part of the MXNet
> repository [2]. Now, everyone can produce similar published artifacts for
> their own needs and we can better verify the release production code as
> part of the Jenkins CI.
>
> Using his contribution, we have created a new job on the MXNet Jenkins for
> publishing artifacts on a nightly basis [3]. In order to ensure the highest
> quality for our releases regardless of user system, it will automatically
> test the artifacts across other distributions including Ubuntu 16.04,
> Ubuntu 18.04, and CentOS 7 as part of the deployment.
>
> You can find the code for the nightly publish pipeline on the repo [4]. We
> hope that others can work off of this pipeline to help expand the same
> static building and thorough testing to additional MXNet packages and
> language bindings in the future.
>
> Special thanks to Qing for his help throughout the project, Sheng for the
> binary build logic, Marco for his reviews and support working with Jenkins,
> Anton for setting up the development Jenkins for us, and Frank and Naveen
> for work on the Scala maven build and deployment.
>
> Zach
>
> [1] - https://repository.apache.org/#nexus-search;quick~org.apache.mxnet
> [2] -
> https://github.com/apache/incubator-mxnet/tree/master/tools/staticbuild
> [3] -
>
> http://jenkins.mxnet-ci.amazon-ml.com/job/restricted-publish-artifacts/job/master/
> [4] - https://github.com/apache/incubator-mxnet/tree/master/ci/publish
>

Re: Taxonomy on our cwiki

[Carin Meier]

+1 Great idea

On Fri, Jan 18, 2019 at 2:38 PM Sheng Zha  wrote:

> Hi MXNet,
>
> Given that currently cwiki is the only place other than mxnet website for
> mxnet-related documentation, I'd like to request your attention to the
> (slightly disorganized) cwiki page of MXNet. The top level folders (and
> their contents) currently looks like this:
> - Design Proposals* (bag of proposals, not in order)
> - Development* (mixture of guides, roadmaps, processes)
> - Release Process (release notes)
> - Website (guides and proposals)
> - MXNet Clojure (call for contribution, guides)
> - MXNet Keras Integration (design)
> - MXNet-ONNX Integration (design, dev status)
> - MXNet R Package (guide, backlog)
> - MXNet-Scala (design, dev status, guide)
> - Content Formatting Templates (not a folder but link to two docs)
> - How-to articles (1 guide)
> - Community (guide on apache-related processes)
> - Data IO (designs)
> - Continuous Integration (guides, designs)
> - Meetups and Hangouts (events)
>
> And here are two good examples from successful Apache projects:
> - Apache Flink: an **audience-oriented** structure [1]
>   Users (Presentations and How-to)
>   Contributors (Dev processes and How-to)
>   Committers (Infra, Dev processes, Release processes, Releases)
>   Roadmaps and Feature Designs (archive)
> - Apache OpenNLP: a **content-oriented** structure [2]
>   Guides
>   External Resources
>   Proposals
>   Releasing
>
> Clean organization helps content discovery and saves time on locating
> useful content. Given that we have good amount of content on the wiki page,
> I suggest that we decide on a cleaner taxonomy, re-organize contents
> accordingly, and add future contents accordingly. To provide a starting
> point for the discussion, I suggest:
> - Given the state we are in, start with content-oriented organization, use
> these top-level categories: Guides (including processes and how-tos),
> Development (including designs, proposals, notes, roadmaps), Community
> (including events, activities, external resources and contents)
> - If people strongly prefer audience-oriented structure, later we can adopt
> a structure similar to Flink's.
>
> Feel free to share your thoughts and preferences here. Thanks.
>
> -sz
>
> [1]
>
> https://cwiki.apache.org/confluence/display/FLINK/Apache+Flink+Homehttps://cwiki.apache.org/confluence/display/FLINK/Apache+Flink+Home
> [2] https://cwiki.apache.org/confluence/display/OPENNLP/Index
>

Re: Questions about MXNet Incubation

[Carin Meier]

Thanks Bob and Isabel for the feedback and answers :)

Isabel, I took your suggestion and started a thread on dev@community :

https://lists.apache.org/thread.html/b59ac198363bd5691cf2a8ef524643e6838c6ea2b679a0ba97d12d17@%3Cdev.community.apache.org%3E

- Carin

On Thu, Jan 17, 2019 at 2:14 AM Isabel Drost-Fromm 
wrote:

>
>
> Am 17. Januar 2019 00:26:04 MEZ schrieb Bob Paulin :
> >> *What are the benefits of graduation for the project and our end
> >users?*
> >This is one of those: "It's more about the Journey than the end
> >destination."  Projects that complete incubation have demonstrated that
> >they meet a certain bar.  And while that by no means guarantee eternal
> >success it does mean that you have met the ASF standard for exit which
> >is not easy.  It means that going forward a report will be submitted to
> >the board describing how your project is doing that end users will be
> >able to read.  This is beyond "How many stars or downloads per month"
> >type of stats that let your user community know you're not going away
> >anytime soon.  One of the criticisms I often hear of the ASF is that
> >projects just don't die (usually around some project that they believe
> >is old or should be deprecated).   To me this is a feature since as
> >long
> >as people care about the project it can live as long as it wants.
>
> That's a nice summary of what the goal of having an incubator is.
> Something I personally would love to know is what other projects having
> gone through the process think of it's benefits and drawbacks, what really
> was it that changed on their journey through the incubator and into being a
> tlp.
>
> Carin (or anyone else really), with the 20th anniversary of the ASF coming
> up - would you mind starting a thread on the topic over at dev@community
> and reach out to other projects (both recently graduated and well
> established and popular) and look for some answers to the question? Would
> be great if others on this list could help with gathering that
> information...
>
> Isabel
>
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>

Questions about MXNet Incubation

[Carin Meier]

I was a guest on a podcast the other day talking about MXNet and I got
asked some questions about what it meant for MXNet to be in the incubator.
I tried to answer them the best I could, but I wasn't too sure if my
responses were right.

I thought I would ask them here so that I can be more informed the next
time someone asks.

*What does it mean that MXNet is incubating?*
(I said that it is the process by which all new projects come through the
Apache project. It gives the project time to have a Apache deploy process,
all the licenses compatible, and the community time to form in the ASF way)

*What will happen when it graduates?*
I said it will be a top-level project. Is this true?

*Where is it in the incubator process?*
I said it is in the community building phase.

This questions wasn't asked but I would like to know the answer so I can
speak to it.

*What are the benefits of graduation for the project and our end users?*

Thanks for any feedback,
Carin

Re: Question about notification on nightly test failures

[Carin Meier]

The Clojure package now has turned the examples into integration tests that
we would like to have CI run. It takes about 15 min for them to complete.

We have a PR in progress
https://github.com/apache/incubator-mxnet/pull/13624

I would like to propose that we run these as part of the regular CI until
the notifications for nightly builds get implemented. We will run on a
whitelist or have an exclude list so that any problematic tests can be
disabled if needed.

Please let me know any feedback on this or concerns.

Thanks,
Carin


On Tue, Jan 15, 2019 at 12:24 PM Pedro Larroy 
wrote:

> Why don't we enable a slack notifier?  I think it would be useful to
> interact with notifications from slack directly, including the label
> bot for example.
>
> Pedro.
>
> On Sun, Jan 13, 2019 at 1:55 AM Carin Meier  wrote:
> >
> > Thanks for the explanation Marco :)
> >
> > - Carin
> >
> > On Sat, Jan 12, 2019 at 7:43 PM Marco de Abreu 
> > wrote:
> >
> > > Hi Carin,
> > >
> > > thanks for thinking about adding nightly tests to clojure, I'm sure
> this
> > > will be of big benefit!
> > >
> > > You're right, the email system is in place but we basically disabled
> the
> > > service December 2017 because it was flooding the inboxes of everybody.
> > >
> > > We've been thinking about various notification methods, but were always
> > > afraid making the notifications meaningless if they come too frequently
> > > (which is WAY better now, thanks to everybody's efforts around
> stabilizing
> > > the tests!) because people would filter them.
> > >
> > > I like the idea of a specific slack channel for the notifications. Are
> > > there any alternatives the community could think of?
> > >
> > > Best regards,
> > > Marco
> > >
> > >
> > > Am Sa., 12. Jan. 2019, 10:11 hat Carin Meier 
> > > geschrieben:
> > >
> > > > The Clojure package is thinking of adding some nightly tests and I'd
> like
> > > > to understand how the notification works in case of failure.
> > > >
> > > > The code in the nightly Jenkins file
> > > >
> > > >
> > >
> https://github.com/apache/incubator-mxnet/blob/master/tests/nightly/Jenkinsfile#L135
> > > > seems to indicate that the failure is emailed. But where does this
> email
> > > > go?
> > > > If you are a contributor, do you get notified of this?
> > > >
> > > > I don't remember seeing any notification of nightly failures, so I'm
> > > > wondering how this works and if there are any improvements to
> > > accessibility
> > > > that we can make, (like maybe posting it to a slack room)?
> > > >
> > > > Thanks,
> > > > Carin
> > > >
> > >
>

Re: Jira board and Confluence page for Julia

[Carin Meier]

Iblis,

Thanks for taking the lead in doing this. Unfortunately, I can't help you
with JIRA  - but maybe someone else can.

I can help you with the wiki. The Clojure package has done something
similar here
https://cwiki.apache.org/confluence/display/MXNET/Clojure+Release+Process.

Once you are logged on you can go here:
https://cwiki.apache.org/confluence/display/MXNET/ and hit "Create Page" on
top. It will create a page in the tree structure it is currently in - so
you can make "Julia Package" - After that you can create sub pages of the
Julia package page.

You should also be able to edit any other page as well. You can also "move"
a page to another spot as well. Under the "..." on the right side, there is
an option.

Let me know if you you need any other help,

Carin

On Sun, Jan 13, 2019 at 9:03 PM iblis  wrote:

> Hi,
>
> I want to create some issue for Julia on Jira board.
> Could we have a category for the Julia package?
> Also, I want to write down something like release process for Julia,
> maybe Confluence wiki is the right replace.
> How to creating a new page on this wiki?
>
> --
> Iblis Lin
> 林峻頤
>

Re: Question about notification on nightly test failures

[Carin Meier]

Thanks for the explanation Marco :)

- Carin

On Sat, Jan 12, 2019 at 7:43 PM Marco de Abreu 
wrote:

> Hi Carin,
>
> thanks for thinking about adding nightly tests to clojure, I'm sure this
> will be of big benefit!
>
> You're right, the email system is in place but we basically disabled the
> service December 2017 because it was flooding the inboxes of everybody.
>
> We've been thinking about various notification methods, but were always
> afraid making the notifications meaningless if they come too frequently
> (which is WAY better now, thanks to everybody's efforts around stabilizing
> the tests!) because people would filter them.
>
> I like the idea of a specific slack channel for the notifications. Are
> there any alternatives the community could think of?
>
> Best regards,
> Marco
>
>
> Am Sa., 12. Jan. 2019, 10:11 hat Carin Meier 
> geschrieben:
>
> > The Clojure package is thinking of adding some nightly tests and I'd like
> > to understand how the notification works in case of failure.
> >
> > The code in the nightly Jenkins file
> >
> >
> https://github.com/apache/incubator-mxnet/blob/master/tests/nightly/Jenkinsfile#L135
> > seems to indicate that the failure is emailed. But where does this email
> > go?
> > If you are a contributor, do you get notified of this?
> >
> > I don't remember seeing any notification of nightly failures, so I'm
> > wondering how this works and if there are any improvements to
> accessibility
> > that we can make, (like maybe posting it to a slack room)?
> >
> > Thanks,
> > Carin
> >
>

Re: Julia Package Release Process

[Carin Meier]

I think you need admin permissions on both repos to do that which might be
problematic. Since it looks like there is just one recent open issue, can
you replicate it on the main MXNet repo and have a link to the original
issue?

FWIW - When the Clojure package joined the main repo. I just put
instructions on the main page to open issues against the main repo instead
https://github.com/gigasquid/clojure-mxnet

- Carin

On Mon, Jan 7, 2019 at 9:13 AM iblis  wrote:

> just found that I don't have the permission to transfer issues of
> dmlc/MXNet.jl.
> Could anyone help me on this?
>
> On 1/7/19 12:16 PM, iblis wrote:
> > okay.
> > Before disabling the issue tracker, I'm going to transfer the issue
> > from MXNet.jl to main repo.
> > (via
> https://help.github.com/articles/transferring-an-issue-to-another-repository/
> )
> >
> > On 1/7/19 12:17 AM, Chris Olivier wrote:
> >> +1 for disabling issue tracker and putting a note on original repo (if
> it
> >> isn’t already there) that work/issue tracking has moved to mxnet (using
> >> julia label in github or Jira). m
> >>
> >>
> >> On Sun, Jan 6, 2019 at 1:19 AM iblis  wrote:
> >>
> >>> Before PR #10149 got merged (Oct 5, 2018) into main repo,
> >>> julia code is developed and maintained in the separate repo --
> >>> dmlc/MXNet.jl.
> >>>
> >>> After that PR, there are no further development happened in
> dmlc/MXNet.jl.
> >>> We work with the main repo now.
> >>> But the original MXNet.jl repo is still there, it just isn't deleted or
> >>> archived yet.
> >>> I receive some issue ticks from this repo occasionally,
> >>> maybe we should just disable the issue tracker of it.
> >>>
>  Does it work with other frameworks other than mxnet?
> >>> hmm, I'm not sure what you mean.
> >>>
> >>> On 1/6/19 1:18 PM, Chris Olivier wrote:
>  Curious:  Why is the julia code maintained in a separate repo? I was
> >>> under
>  the impression that it was donated/permanently merged into the mxnet
> >>> source
>  tree.  Does it work with other frameworks other than mxnet?
> 
>  On Sat, Jan 5, 2019 at 8:32 PM Iblis Lin 
> wrote:
> 
> > If there is trademark issue, how about this option:
> >  3) transferring the MXNet.jl repo ownership from DMLC to Apache.
> >
> > On 1/6/19 6:45 AM, Justin Mclean wrote:
> >> Hi,
> >>
> >>> 1) Reuse the old repo: https://github.com/dmlc/MXNet.jl
> >>>It's under DMLC. I have the committer bit of this repo.
> >>
> >> I'm not 100% sure that would be allowed from a branding/trademark
> > perspective, any distribution owned by a 3rd party can't be called
> >>> "Apache
> > MXNet".
> >>
> >>> 2) A new repo under ASF's organization?
> >>
> >> That seems preferable I think.
> >>
> >> Thanks,
> >> Justin
> >>
> >
> > --
> > Iblis Lin
> > 林峻頤
> >
> 
> >>>
> >>> --
> >>> Iblis Lin
> >>> 林峻頤
> >>>
> >>
> >
>
> --
> Iblis Lin
> 林峻頤
>

Re: Julia Package Release Process

[Carin Meier]

Iblis,

Thank you for your work in developing a release process for the Julia
package. Thanks especially for explaining it in way that is approachable
for others not familiar with the Julia dependency management system.

I know there are some conditions under which Apache can distribute releases
downstream.

>From this conversation
https://issues.apache.org/jira/browse/LEGAL-270

It seems that "it is appropriate to distribute official releases through
downstream channels".
Another github repo seems like it could be a downstream channel for ease
with Julia deps.

I don't know whether the DMLC repo would be a problem with the naming or as
long as it specified it was a distribution of the Apache (incubating) MXNet
project it would be ok.

Do you know of any other Julia Apache projects? Maybe we could look and see
how they are doing it.

Best,
Carin


On Sat, Jan 5, 2019 at 11:00 AM iblis  wrote:

> Hello MXNet community,
>
> After the Julia package has been imported into the main repo,
> the next unresolved issue is establishing the releasing process for Julia.
>
> The PR #12845, which is for upgrading Julia package to work with Julia
> v0.7+,
> is ready for review at this moment.
> I want to release the Julia part along with the next mxnet major release
> (v1.5, I think).
>
> We imported the Julia package to make it part of the CI validation chain.
> And merging code into main repo makes Julia release process different from
> normal.
>
> At first, let me describe a usual release process for a Julia package.
> I will try to explain it with corresponding ideas in Python.
>
> 1.Package manager in Julia:
>  There are a module from stdlib named `Pkg` served as the package
> manager in Julia,
>  like Python's `pip`.
>
> 2. The package registry and package source:
>  The package manager will download the desired packages from a default
> registry.
>  In Python, pip will conduct two actions before installing packags:
> (1) Search the metadata (like pkg name, version, ...etc)
> from the CheeseShop (a.k.a PyPI) for users.
> (2) Fetch them from the CheeseShop if matched.
>
>  In Julia, there is a default registry to hold the packages metadata,
>  hosted on GitHub:
>https://github.com/JuliaLang/METADATA.jl
>
>  And where to fetch the package? The aren't a center for download
> packages.
>  It's unlike Python's idea, we don't upload package to a center server
> in case of Julia.
>
>  The package manager will fetch stuffs from the URL listed in the
> metadata.
>  It should be a valid git URL for git-clone.
>  e.g. For the package `Distributions`:
>
> https://github.com/JuliaLang/METADATA.jl/blob/metadata-v2/Distributions/url
>  Most of the packages use GitHub for hosting code.
>
> 3. A valid package directory structure
>
>  In the process of package installation,
>  Python's pip will run `./setup.py` from unpacked package dir.
>  This is kind of protocol between package developer and package
> manager.
>
>  In Julia, the package manager run `./deps/build.jl` from the
> git-cloned dir.
>
>  Here comes an issue of mxnet's main repo.
>  The Julia package is collected under the subdir `./julia/`, so the
> setup script
>  in our case is `./julia/deps/build.jl`.
>  This breaks the protocol.
>
>  Also, in runtime, there is another protocol for phase of module
> loading.
>  The entry point of a module must be `./src/PackageName.jl`.
>  In our repo, it's `./julia/src/MXNet.jl`.
>  So, the directory structure of mxnet main repo is invalid for Julia
> package manager.
>  Putting the url of main repo as package metadata will not work.
>
> The proposed solution:
>
>To provide a valid dir structure, it need a standalone git repo.
>We can just treat this standalone repo as the place to "upload" package
> code,
>just like uploading Python package to PyPI in every release.
>
>I want to discuss about the home of this standalone repo.
>  1) Reuse the old repo: https://github.com/dmlc/MXNet.jl
> It's under DMLC. I have the committer bit of this repo.
>  2) A new repo under ASF's organization?
>  3) Anything else?
>
>I will vote for option (1).
>
>
>The actual process in detail:
>  1) Split the julia dir out via git-subtree
>  ```
>  cd /path/to/mxnet/
>  git subtree split -P julia -b MXNet_jl
>  ```
>
>  2) Push the branch `MXNet_jl` to the standalone git repo mentioned in
> previous section.
>
>  3) Push a new tag for MXNet.jl. The version number is same as the
> mxnet main repo.
>
>  4) Make a release page via GitHub release button.
>
>  5) Then, updating metadata to Julia package registry will be
> automated by the bot.
> https://github.com/attobot/attobot
>
>  6) Relax!
>
> --
> Iblis Lin
>

[Annoucement] New Committer -- Iblis Lin

[Carin Meier]

Please join me in welcoming Iblis Lin as a new committer.

He has been a long time contributor to the Julia package, is responsible
for bringing into the main MXNet repo, and is the current maintainer.

https://github.com/apache/incubator-mxnet/commits?author=iblis17

- Carin Meier

MLConf 2019 Call for Abstracts/Talks

[Carin Meier]

The Machine Learning Conference has a Call for Abstracts/Talks open until
12/31.

https://mlconf.com/abstract-guideline

It would be great opportunity to talk about the power of MXNet.
Please consider submitting!

- Carin

Re: [DISCUSS] About the PR merging policy

[Carin Meier]

Thanks Steffen,

I had remembered reading that but couldn't find it again :)

So yes - maybe we can duplicate that section and/or provide a link to a new
committers guide.

I'm thinking it should go on the community page here
https://cwiki.apache.org/confluence/display/MXNET/Community

Eventually, some of information collected there could migrate out the
webpage as well.

- Carin

On Thu, Dec 13, 2018 at 7:30 AM Steffen Rochel 
wrote:

> We do have already a guide which covers the issue:
>
> https://cwiki.apache.org/confluence/display/MXNET/Development+Process#DevelopmentProcess-GuidelinesforReviewers/Committers
> <
> https://cwiki.apache.org/confluence/display/MXNET/Development+Process#DevelopmentProcess-GuidelinesforReviewers/Committers
> >,
> but it probably needs to become more prominent. Any suggestion for a good
> place?
> Steffen
>
> On Wed, Dec 12, 2018 at 5:23 PM Carin Meier  wrote:
>
> > Qing - thanks for bringing this up.
> >
> > I think it would be a good thing to have a document on the wiki to help
> > with these sorts of questions.
> >
> > In fact, since the project is growing with more new committers, maybe we
> > could use a "New Committer Guide" with the process of how to get going
> and
> > any FAQ like this one ...
> >
> > Would you be interested in getting a rough draft going of your recent
> > experience? Then others can help collaborate on it.
> >
> > It would be nice to make the path smoother for other new committers to
> the
> > project.
> >
> > Best,
> > Carin
> >
> > On Tue, Dec 11, 2018 at 7:18 PM Qing Lan  wrote:
> >
> > > Hi all,
> > >
> > > Recently I self-merged my PR without getting approvals from other
> > > committers https://github.com/apache/incubator-mxnet/pull/13617 and
> only
> > > contributors approval. I apologize to the community and thank Marco for
> > > pointing out the problem. I took a lesson that we should at least have
> > one
> > > committer’s approval to merge the code. However, I just found this
> > section
> > > is missing in the CWiki
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member
> > .
> > > So I would like to discuss in here:
> > >
> > > How to conduct the PR reviewing/merging. How many approvals (Committers
> > > and Contributors) we should get in order to merge?
> > >
> > > How to deal with disagreement in the discussion (e.g a
> > > contributor/committer request a change)?
> > >
> > > Please don’t hesitate to share your thoughts!
> > >
> > > Thanks,
> > > Qing
> > >
> >
>

Re: Julia CI Package

[Carin Meier]

I would create an issue for it and ping Iblis Lin on it
https://github.com/apache/incubator-mxnet/pulls?q=is%3Apr+author%3Aiblis17
- He is the contributor that brought in the Julia package and got the CI
process running with it so he might have more insight.

- Carin

On Fri, Dec 14, 2018 at 2:38 PM Alex Zai  wrote:

> Is anyone familiar with the Julia build and can help debug an issue where
> the Julia stage in the CI just hangs? I have made a change where I am
> making mkldnn default on the master branch. This means that the julia
> package now is being build with a version of mxnet that is linking to
> mkldnn). The julia stage on the CI just hangs without any error message and
> gets killed after the 2 hour timeout (
>
> http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/mxnet-validation%2Funix-cpu/detail/PR-13464/40/pipeline
> ).
>
> Alex
>

Re: [DISCUSS] About the PR merging policy

[Carin Meier]

Qing - thanks for bringing this up.

I think it would be a good thing to have a document on the wiki to help
with these sorts of questions.

In fact, since the project is growing with more new committers, maybe we
could use a "New Committer Guide" with the process of how to get going and
any FAQ like this one ...

Would you be interested in getting a rough draft going of your recent
experience? Then others can help collaborate on it.

It would be nice to make the path smoother for other new committers to the
project.

Best,
Carin

On Tue, Dec 11, 2018 at 7:18 PM Qing Lan  wrote:

> Hi all,
>
> Recently I self-merged my PR without getting approvals from other
> committers https://github.com/apache/incubator-mxnet/pull/13617 and only
> contributors approval. I apologize to the community and thank Marco for
> pointing out the problem. I took a lesson that we should at least have one
> committer’s approval to merge the code. However, I just found this section
> is missing in the CWiki
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member.
> So I would like to discuss in here:
>
> How to conduct the PR reviewing/merging. How many approvals (Committers
> and Contributors) we should get in order to merge?
>
> How to deal with disagreement in the discussion (e.g a
> contributor/committer request a change)?
>
> Please don’t hesitate to share your thoughts!
>
> Thanks,
> Qing
>

Re: Should PR-860 (Use modernized range loops where possible) be reverted?

[Carin Meier]

Great. Thanks for the clarifications everyone. I think we are good then :)

- Carin

On Tue, Nov 20, 2018 at 10:43 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Hey Carin, I don't think there's any issues merging this PR.  The veto'd
> aspect was around _requiring_ modern loop usage, and failing the build if
> clang tidy detected modern loops could be used but weren't.  The original
> PR included a check for this and would fail any builds not using modern
> loops.  Several people didn't like this aspect so I updated the PR and
> removed that overly-strict check.  The current PR doesn't have anything it
> in that's been vetod.  We're continuing to warn if clang-tidy detects a
> loop could be modernized, but are not causing an error (which was actually
> the behaviour before this PR was merged).
>
> On Tue, Nov 20, 2018 at 7:29 AM Anton Chernov  wrote:
>
> > Hi Carin,
> >
> > The discussion [1] was about whether to enable automatic checks on using
> > old behaviour in new PR's. Kellens PR [2] was about modernizing the
> actual
> > code itself and was not up for voting, thus could not receive any
> technical
> > veto votes.
> >
> > Per the discussion (as I have understood it), we won't get veto votes if
> we
> > would enable the check on CI, if it would be treated as a warning.
> >
> > Thank you for merging the PR in the first place. I see no reason for
> > reverting it.
> >
> > Best
> > Anton
> >
> > [1]
> >
> >
> https://lists.apache.org/thread.html/b47f285a80bef47c5ead6c361614e338a0661f6c0c76196c1e3719c5@%3Cdev.mxnet.apache.org%3E
> > [2] https://github.com/apache/incubator-mxnet/pull/12356
> >
> >
> > вт, 20 нояб. 2018 г. в 15:24, Pedro Larroy  >:
> >
> > > Hi all
> > >
> > > I think we have to make the clear separation between the thread votes
> > > on "uniformly adopting C++11 range loops in the MXNet project" and a
> > > PR which refactored code to be more legible and with improved variable
> > > names.
> > > Merging that PR doesn't imply that we have to uniformly adopt the
> > > previous proposal.  The PR was reviewed and approved by several
> > > people. I would keep the two topics separate, merging this PR doesn't
> > > prescribe any particular idiom for future commits or reviews.
> > >
> > > Pedro.
> > >
> > > On Tue, Nov 20, 2018 at 2:58 PM Carin Meier 
> > wrote:
> > > >
> > > > My intent was to be helpful, but I think I may have merged this PR
> > > > yesterday too soon thinking it was approved and ready to merge
> > > > https://github.com/apache/incubator-mxnet/pull/12356
> > > >
> > > > I didn't see the connected dev discussion
> > > >
> > >
> >
> https://lists.apache.org/thread.html/b47f285a80bef47c5ead6c361614e338a0661f6c0c76196c1e3719c5@%3Cdev.mxnet.apache.org%3E
> > > > where there were -1 votes, which I believe are vetos?
> > > >
> > > > So the question is confirm: should PR should be reverted?
> > > >
> > > > Sorry for any confusion,
> > > > Carin
> > >
> >
>

Should PR-860 (Use modernized range loops where possible) be reverted?

[Carin Meier]

My intent was to be helpful, but I think I may have merged this PR
yesterday too soon thinking it was approved and ready to merge
https://github.com/apache/incubator-mxnet/pull/12356

I didn't see the connected dev discussion
https://lists.apache.org/thread.html/b47f285a80bef47c5ead6c361614e338a0661f6c0c76196c1e3719c5@%3Cdev.mxnet.apache.org%3E
where there were -1 votes, which I believe are vetos?

So the question is confirm: should PR should be reverted?

Sorry for any confusion,
Carin

Re: [VOTE] Release Apache MXNet (incubating) version 1.3.1.rc0

[Carin Meier]

+1 - Clojure package tested fine with Scala jars

On Mon, Nov 12, 2018 at 6:53 PM Anton Chernov  wrote:

> Dear MXNet community,
>
> This is the vote to release Apache MXNet (incubating) version 1.3.1. Voting
> will start now, on Monday the 12th of November 2018 and close on 14:00
> Thursday the 15th of November 2018, Pacific Time (PT).
>
> Link to release notes:
> https://cwiki.apache.org/confluence/x/eZGzBQ
>
> Link to release candidate 1.3.1.rc0:
> https://github.com/apache/incubator-mxnet/releases/tag/1.3.1.rc0
>
> Link to source and signatures on apache dist server:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.3.1.rc0/
>
> Link to scala packages on the staging repo:
>
> * CPU
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/mxnet/mxnet-full_2.11-osx-x86_64-cpu/1.3.1-SNAPSHOT/
>
> * GPU
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/mxnet/mxnet-full_2.11-linux-x86_64-gpu/1.3.1-SNAPSHOT/
>
> Please remember to TEST first before voting accordingly:
> +1 = approve
> +0 = no opinion
> -1 = disapprove (provide reason)
>
>
> Best regards,
> Anton
>

Re: [VOTE] Separating PMC and Committership

[Carin Meier]

Reminder - Vote ends tomorrow-  Friday Nov 9th at 6:00 am EST

On Mon, Nov 5, 2018 at 11:29 AM Carin Meier  wrote:

> This is a procedural vote on whether to separate the committer and PPMC
> levels in the project. The current state is that a user is considered as
> both a committer and a PPMC member at the same time. This vote is to change
> that to be able to invite a person in as a committer separately from a PPMC
> member.
>
> Document reference:
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member
>
> Discussion thread:
> https://lists.apache.org/thread.html/9c6ecda02e081aa6b689c92badc9dcf05ced6fb3691fd370471773d1@%3Cdev.mxnet.apache.org%3E
>
> The vote will be a procedural issue vote as defined
> https://www.apache.org/foundation/voting.html
>
> Votes on procedural issues follow the common format of majority rule unless
> otherwise stated. That is, if there are more favourable votes than
> unfavourable ones, the issue is considered to have passed -- regardless of
> the number of votes in each category. (If the number of votes seems too
> small to be representative of a community consensus, the issue is typically
> not pursued. However, see the description of lazy consensus
> <https://www.apache.org/foundation/voting.html#LazyConsensus> for a
> modifying factor.)
>
> The vote will run until Friday Nov 9th at 6:00 am EST
>
> Thanks,
> Carin
>
>
>

[VOTE] Separating PMC and Committership

[Carin Meier]

This is a procedural vote on whether to separate the committer and PPMC
levels in the project. The current state is that a user is considered as
both a committer and a PPMC member at the same time. This vote is to change
that to be able to invite a person in as a committer separately from a PPMC
member.

Document reference:
https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member

Discussion thread:
https://lists.apache.org/thread.html/9c6ecda02e081aa6b689c92badc9dcf05ced6fb3691fd370471773d1@%3Cdev.mxnet.apache.org%3E

The vote will be a procedural issue vote as defined
https://www.apache.org/foundation/voting.html

Votes on procedural issues follow the common format of majority rule unless
otherwise stated. That is, if there are more favourable votes than
unfavourable ones, the issue is considered to have passed -- regardless of
the number of votes in each category. (If the number of votes seems too
small to be representative of a community consensus, the issue is typically
not pursued. However, see the description of lazy consensus
 for a
modifying factor.)

The vote will run until Friday Nov 9th at 6:00 am EST

Thanks,
Carin

Re: [Discussion] Separating PMC and Committership

[Carin Meier]

If there are no objections, I plan to start a vote on this tomorrow (Monday)

- Carin

On Fri, Nov 2, 2018 at 10:24 AM Carin Meier  wrote:

> Haibin - Now that the updated document on "Becoming a Committer and PPMC
> Member" has been adopted by the community, would you be interested in
> starting a procedural vote on this?
>
> If not, I'd be happy to facilitate, but since it was your idea to start
> off with, I thought I would ask :)
>
> Best,
> Carin
>
> On Tue, Oct 9, 2018 at 2:11 PM Haibin Lin 
> wrote:
>
>> Dear MXNet community,
>>
>> In the past when we invite a person to become a committer, he/she is
>> automatically made a PMC member. However, a lot of communities keep a
>> small
>> PMC, and a bigger and more diverse committers to enrich the community.
>> This
>> has the benefit of having two opportunities to encourage contribution.
>> This
>> can also help lower the bar for inviting committers, which helps build
>> consensus in our already large PMC. I'd like to propose the following:
>>
>> For active contributors we first invite them to become our committers.
>> Later on as they make significant contribution, we can invite them to PMC.
>>
>>
>> ===
>> Comments from Marco:
>>
>> That's a great idea!
>>
>> The hard question is how to differentiate between a committer and a PMC
>> member and where we set the bar for each. If I understand you right, you
>> are proposing to honor active contributions by volume (or another similar
>> metric). While I think that's a good idea in general, I have a few
>> thoughts:
>>
>> We definitely have a lot of active people in the project, but let's say
>> that they contribute a substantial amount, but their contributions can't
>> go
>> in as-is because they lack quality, consistency, testing or they don't
>> match with the overall style and best practices. For a code-committer,
>> this
>> would still be a no-go in my opinion. That person would still require some
>> guidance and mentoring until they are aligned with the project style and
>> guidelines as otherwise they might accept low-quality PRs. I know we can
>> revert that, but let's avoid confrontation as much as possible.
>>
>> The minimum bar for a code committer would then be:
>> - (almost) unaltered acceptance of their PRs (of course, some PRs are
>> intentionally made for discussions and those would even be a plus!)
>> - following mxnets community guidelines, rules and styles
>> - giving useful reviews (in order to see how they would be as reviewers if
>> they were a committer)
>> The would be weighted differently on a case by case base, but this could
>> be
>> a starting point to describe what we are looking for.
>>
>> From committer to PMC on the other hand, the difference is quite small.
>> Something I personally would be looking for are three things:
>> - judgement
>> - community engagement
>> - Apache way
>> While a committer might be chosen due to their contributions, they
>> wouldn't
>> be evaluated that strictly for the above points. A PMC member is a
>> representative of the project who steers the long term development of it.
>> Thus, they should be active on our channels like dev@, make good reviews
>> on
>> GitHub (if applicable), express good judgement and reasoning during votes
>> and generally show that they are generally helpful to the project on a
>> non-code level.
>>
>> These are just some thoughts of mine to help start of this discussions. It
>> would be good to hear what other people are looking for while evaluating
>> candidates and if there's anything they would like to highlight.
>>
>> ==
>>
>> Comments from Carin:
>>
>> I think it is a good idea. Here is a bit of reasoning behind my thoughts.
>>
>> *Pros of separating Committer and PMC *
>>  - It would allow us to bring on more committers than the previous
>> criteria
>> which would help in giving people the tools they need to be productive.
>>  - The increased productivity should allow PRs to be reviewed and merged
>> more quickly.
>>  - Provide a more welcoming experience for people posting new PRs to have
>> them processed faster.
>>  - Also provide an additional layer of membership (PMC) after a committer
>> to help motivate involvement.
>>
>> *Cons of separating*
>>  - There is a possibility of having someone as a committer that isn't as
>> closely 

Re: [Discussion] Separating PMC and Committership

[Carin Meier]

Haibin - Now that the updated document on "Becoming a Committer and PPMC
Member" has been adopted by the community, would you be interested in
starting a procedural vote on this?

If not, I'd be happy to facilitate, but since it was your idea to start off
with, I thought I would ask :)

Best,
Carin

On Tue, Oct 9, 2018 at 2:11 PM Haibin Lin  wrote:

> Dear MXNet community,
>
> In the past when we invite a person to become a committer, he/she is
> automatically made a PMC member. However, a lot of communities keep a small
> PMC, and a bigger and more diverse committers to enrich the community. This
> has the benefit of having two opportunities to encourage contribution. This
> can also help lower the bar for inviting committers, which helps build
> consensus in our already large PMC. I'd like to propose the following:
>
> For active contributors we first invite them to become our committers.
> Later on as they make significant contribution, we can invite them to PMC.
>
>
> ===
> Comments from Marco:
>
> That's a great idea!
>
> The hard question is how to differentiate between a committer and a PMC
> member and where we set the bar for each. If I understand you right, you
> are proposing to honor active contributions by volume (or another similar
> metric). While I think that's a good idea in general, I have a few
> thoughts:
>
> We definitely have a lot of active people in the project, but let's say
> that they contribute a substantial amount, but their contributions can't go
> in as-is because they lack quality, consistency, testing or they don't
> match with the overall style and best practices. For a code-committer, this
> would still be a no-go in my opinion. That person would still require some
> guidance and mentoring until they are aligned with the project style and
> guidelines as otherwise they might accept low-quality PRs. I know we can
> revert that, but let's avoid confrontation as much as possible.
>
> The minimum bar for a code committer would then be:
> - (almost) unaltered acceptance of their PRs (of course, some PRs are
> intentionally made for discussions and those would even be a plus!)
> - following mxnets community guidelines, rules and styles
> - giving useful reviews (in order to see how they would be as reviewers if
> they were a committer)
> The would be weighted differently on a case by case base, but this could be
> a starting point to describe what we are looking for.
>
> From committer to PMC on the other hand, the difference is quite small.
> Something I personally would be looking for are three things:
> - judgement
> - community engagement
> - Apache way
> While a committer might be chosen due to their contributions, they wouldn't
> be evaluated that strictly for the above points. A PMC member is a
> representative of the project who steers the long term development of it.
> Thus, they should be active on our channels like dev@, make good reviews
> on
> GitHub (if applicable), express good judgement and reasoning during votes
> and generally show that they are generally helpful to the project on a
> non-code level.
>
> These are just some thoughts of mine to help start of this discussions. It
> would be good to hear what other people are looking for while evaluating
> candidates and if there's anything they would like to highlight.
>
> ==
>
> Comments from Carin:
>
> I think it is a good idea. Here is a bit of reasoning behind my thoughts.
>
> *Pros of separating Committer and PMC *
>  - It would allow us to bring on more committers than the previous criteria
> which would help in giving people the tools they need to be productive.
>  - The increased productivity should allow PRs to be reviewed and merged
> more quickly.
>  - Provide a more welcoming experience for people posting new PRs to have
> them processed faster.
>  - Also provide an additional layer of membership (PMC) after a committer
> to help motivate involvement.
>
> *Cons of separating*
>  - There is a possibility of having someone as a committer that isn't as
> closely aligned to the standards and quality suffers.
> *Possible Mitigation*
> - We do have a robust CI that should ensure that basic functionality
> doesn't break.
> - Do additional communication when a new committer is announced what
> the expectation of the standards of committership is.
> - Two votes now need to happen for a person since there are two levels.
>*Possible Mitigation*
> - If we are convinced the person would be a good PMC member as well, we
> could vote them as both at the same time.
>
> I think it would be a good change to try and see how it works out over a
> period of a few months. The nice thing is that if we feel like it isn't
> working well, we can always change the process.
>
> ==
>
>
> Best,
> Haibin
>

[VOTE][RESULTS] - Adopt "Become a Committer and PPMC Member" Document

[Carin Meier]

The vote passed to adopt the new document
https://lists.apache.org/thread.html/5bbddb085e8b7f5c97623414bb5b98372b56fc9a1dd9f5192d613ee3@%3Cdev.mxnet.apache.org%3E

*+1 Binding*
Tianqi Chen
Sergio Fernández
Chris Oliver
Sebastian Schelter
Naveen Swamy
Yuan Tang

*+1 Non-Binding*
Pedro Larroy
Aaron Markham
Steffen Rochel
Kellen Sunderland

Thanks again everyone involved. I'll move the adopted document and archive
the old one as soon as I figure out how to do that in our wiki :)

- Carin

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

[Carin Meier]

Reminder - vote ends tomorrow morning at 6:00 am EST

On Mon, Oct 29, 2018 at 6:46 PM Carin Meier  wrote:

> This vote is to adopt the document
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> to replace the current document
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>
> The dev discussion thread is here
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
>
> The vote will be a procedural issue vote as defined
> https://www.apache.org/foundation/voting.html
>
> Votes on procedural issues follow the common format of majority rule
> unless otherwise stated. That is, if there are more favourable votes than
> unfavourable ones, the issue is considered to have passed -- regardless of
> the number of votes in each category. (If the number of votes seems too
> small to be representative of a community consensus, the issue is typically
> not pursued. However, see the description of lazy consensus
> <https://www.apache.org/foundation/voting.html#LazyConsensus> for a
> modifying factor.)
>
> The vote will run until Friday Nov 2nd at 6:00 am EST
>
> Thanks,
> Carin
>
>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

[Carin Meier]

Sure PPMC stands for Podling Project Management Committee -
https://incubator.apache.org/guides/ppmc.html - I updated the document to
have  ",(Podling Project Management Committee)," in the both sections with
a link where the abbreviation is first introduced.

- Carin

On Tue, Oct 30, 2018 at 12:09 PM Aaron Markham 
wrote:

> +1 non-binding
> One minor thing first: can you define PPMC in the doc? It's brought in
> without saying what it stands for. Even the link it goes to just talks
> about PMC and there's no mention of PMCC... so I'm not sure what the
> definition is.
>
>
> On Tue, Oct 30, 2018 at 8:07 AM Carin Meier  wrote:
>
> > From the feedback in the thread. I changed the wording of "Privileges" to
> > "Rights and Responsibilities".
> >
> > If I misunderstood anything, please let me know.
> >
> > Best,
> > Carin
> >
> > On Tue, Oct 30, 2018 at 7:00 AM Sergio Fernández 
> > wrote:
> >
> > > +1 since the Beam model is much more open than the current one.
> > >
> > > Here my two cents to the discussion:
> > >
> > > You can see that in the past was different,, but we had evolved as
> > > foundation. As general recommendation, the new way is to spend less
> > effort
> > > in ad-hoc bylaws on every project/podling and adopt the general ones.
> The
> > > easier the project is managed, normally the better the community
> evolves.
> > >
> > > In addition, as a linguistic detail: commiters and/or pmc do not have
> > more
> > > "privileges", but "responsibilities".
> > >
> > > Cheers,
> > >
> > > On Mon, Oct 29, 2018, 15:47 Carin Meier  wrote:
> > >
> > > > This vote is to adopt the document
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > > > to replace the current document
> > > >
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > > >
> > > > The dev discussion thread is here
> > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
> > > >
> > > > The vote will be a procedural issue vote as defined
> > > > https://www.apache.org/foundation/voting.html
> > > >
> > > > Votes on procedural issues follow the common format of majority rule
> > > unless
> > > > otherwise stated. That is, if there are more favourable votes than
> > > > unfavourable ones, the issue is considered to have passed --
> regardless
> > > of
> > > > the number of votes in each category. (If the number of votes seems
> too
> > > > small to be representative of a community consensus, the issue is
> > > typically
> > > > not pursued. However, see the description of lazy consensus
> > > > <https://www.apache.org/foundation/voting.html#LazyConsensus> for a
> > > > modifying factor.)
> > > >
> > > > The vote will run until Friday Nov 2nd at 6:00 am EST
> > > >
> > > > Thanks,
> > > > Carin
> > > >
> > >
> >
>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

[Carin Meier]

Chris,

Is there are rewording that you would find more acceptable? Again, we can
have more time to edit and revise the document. There is not a time limit
on this. I might have been too hasty to start the vote thinking the
discussion was wrapped up.

- Carin

On Mon, Oct 29, 2018 at 8:50 PM Chris Olivier  wrote:

> or another example if something is downvoted, this also implies that after
> a vote is over, it’s approprorate to continue pushing the subject trying to
> just wear everyone down even though the outcome is clear. We’ve seen this
> before, actually.
>
> On Mon, Oct 29, 2018 at 5:41 PM Chris Olivier 
> wrote:
>
> > -1 “strive to meet consensus”? This seems to imply the consensus is the
> > natural expected state. So in the case where someone submits that we
> should
> > start a nuclear war, then our bylaws would state that we should all try
> to
> > agree to start a nuclear war.
> >
> > On Mon, Oct 29, 2018 at 4:41 PM Tianqi Chen  wrote:
> >
> >> Hi Carin:
> >> Sorry for the last minute request, but given the way we write down
> the
> >> PMC, committer privileges, I feel we need to add an additional line:
> >>
> >>- "PMC/committer should strive to be diplomatic and reach consensus
> >> with
> >> discussion when possible."
> >>
> >>    Since I don't really want us to give an impression of abusing veto
> >> rights.
> >>
> >> Thanks!
> >> Tianqi
> >>
> >> On Mon, Oct 29, 2018 at 3:47 PM Carin Meier 
> wrote:
> >>
> >> > This vote is to adopt the document
> >> >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> >> > to replace the current document
> >> >
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> >> >
> >> > The dev discussion thread is here
> >> >
> >> >
> >>
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
> >> >
> >> > The vote will be a procedural issue vote as defined
> >> > https://www.apache.org/foundation/voting.html
> >> >
> >> > Votes on procedural issues follow the common format of majority rule
> >> unless
> >> > otherwise stated. That is, if there are more favourable votes than
> >> > unfavourable ones, the issue is considered to have passed --
> regardless
> >> of
> >> > the number of votes in each category. (If the number of votes seems
> too
> >> > small to be representative of a community consensus, the issue is
> >> typically
> >> > not pursued. However, see the description of lazy consensus
> >> > <https://www.apache.org/foundation/voting.html#LazyConsensus> for a
> >> > modifying factor.)
> >> >
> >> > The vote will run until Friday Nov 2nd at 6:00 am EST
> >> >
> >> > Thanks,
> >> > Carin
> >> >
> >>
> >
>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

[Carin Meier]

Tianqi - I added it the end of the document.

If anyone feels that they need more time to further discuss/revise the
changes, I'm fine with ending/suspending the current vote and resuming it
in the future to enable more collaboration.

Just let me know.

Best,
Carin

On Mon, Oct 29, 2018 at 7:41 PM Tianqi Chen  wrote:

> Hi Carin:
> Sorry for the last minute request, but given the way we write down the
> PMC, committer privileges, I feel we need to add an additional line:
>
>- "PMC/committer should strive to be diplomatic and reach consensus with
> discussion when possible."
>
>Since I don't really want us to give an impression of abusing veto
> rights.
>
> Thanks!
> Tianqi
>
> On Mon, Oct 29, 2018 at 3:47 PM Carin Meier  wrote:
>
> > This vote is to adopt the document
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > to replace the current document
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> >
> > The dev discussion thread is here
> >
> >
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
> >
> > The vote will be a procedural issue vote as defined
> > https://www.apache.org/foundation/voting.html
> >
> > Votes on procedural issues follow the common format of majority rule
> unless
> > otherwise stated. That is, if there are more favourable votes than
> > unfavourable ones, the issue is considered to have passed -- regardless
> of
> > the number of votes in each category. (If the number of votes seems too
> > small to be representative of a community consensus, the issue is
> typically
> > not pursued. However, see the description of lazy consensus
> > <https://www.apache.org/foundation/voting.html#LazyConsensus> for a
> > modifying factor.)
> >
> > The vote will run until Friday Nov 2nd at 6:00 am EST
> >
> > Thanks,
> > Carin
> >
>

[VOTE] - Adopt "Become a Committer and PPMC Member" Document

[Carin Meier]

This vote is to adopt the document
https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
to replace the current document
https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer

The dev discussion thread is here
https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E

The vote will be a procedural issue vote as defined
https://www.apache.org/foundation/voting.html

Votes on procedural issues follow the common format of majority rule unless
otherwise stated. That is, if there are more favourable votes than
unfavourable ones, the issue is considered to have passed -- regardless of
the number of votes in each category. (If the number of votes seems too
small to be representative of a community consensus, the issue is typically
not pursued. However, see the description of lazy consensus
 for a
modifying factor.)

The vote will run until Friday Nov 2nd at 6:00 am EST

Thanks,
Carin

Re: Apache MXNet Scala nightly-build now available on Apache Nexus

[Carin Meier]

Fantastic! This is going to be great for the Clojure MXNet users as well.

On Mon, Oct 29, 2018 at 1:39 PM YiZhi Liu  wrote:

> Hi,
>
>
>
> I am happy to announce that the availability of the experimental
> nightly-build Scala package on Maven in Nexus. The nightly-builds,
> currently published as 1.3.1-SNAPSHOT version, include the latest changes
> from the master branch from apache/incubator-mxnet GitHub repo and refresh
> every day. Furthermore, we completely overhauled the MXNet library shipped
> inside and adopted the binary build logic used for Python pip, so now Scala
> users can also enjoy the portable MXNet with fully loaded features.
> Currently, the supported artifacts are:
>
> - mxnet-full_2.11-linux-x86_64-cpu (Linux-CPU)
>
> - mxnet-full_2.11-linux-x86_64-gpu (Linux-GPU, CUDA 9.0)
>
> - mxnet-full_2.11-osx-x86_64-cpu (OSX-CPU)
>
>
>
> FAQ:
>
> - What's new in the nightly Scala packages compared to the previous Scala
> Maven artifacts?
>
> Most notably, better usability, more supported features, and better
> platform compatibility. The new packages now support Ubuntu 14.04 and
> Amazon Linux and support the same broad set of features as the existing pip
> packages. Besides, users are no longer required to install all the
> dependencies to use the nightly Scala packages as the included MXNet
> libraries are fully loaded. For the list of supported platforms and
> features, see [1].
>
>
>
> - What's different in the build approach compared to what's in the previous
> Scala Maven packages?
>
> The previous Scala Maven packages (1.2, 1.2.1, 1.3) were built with the
> same build commands that regular users would use when building from source
> [2]. This naive approach limits the compatibility to only similar
> environments as where the packages were built (which was Ubuntu 16.04 for
> Linux, and OSX 10.13 for OSX). As a result, users cannot use it on more
> CentOS or Amazon Linux and may suffer the problem of mismatching of
> dependency versions due to the difference in their environment.
>
> On the other hand, Python users have long been enjoying portable and fully
> loaded MXNet packages from pip. The MXNet libraries in pip packages are
> built in more controlled environments with compatibility in mind.
> Dependencies for extended features are statically linked and masked so that
> no additional steps are needed.
>
> Now, in the new Scala nightly packages, the same approach as pip is used
> for building the MXNet library so that the Scala users can benefit from the
> same great features.
>
>
>
> - How do I get the new nightly packages?
>
> You can find the packages on Apache (Snapshots) repository [3] including
> pom files and jars, which you can download and add to your projects.
> Alternatively, you can configure your pom.xml to use the Maven repository.
> Remember to add repository config:
>
> 
>
>   
>
> Apache Snapshot
>
> https://repository.apache.org/content/groups/snapshots
>
>   
>
> 
>
>
>
> - What's the support level of the Scala nightly packages?
>
> This package is currently experimental, so use at your own risk. While the
> first nightly packages are already manually verified on several platforms,
> and the automated publish pipeline runs unit tests and integration tests on
> OSX and Ubuntu 14.04 before publishing, the testing is currently limited.
>
>
>
> - How can I help?
>
> We call on all MXNet Scala community to test out the new nightly packages.
>
>
>
> - I found a problem in using the package. What should I do?
>
> Please report this in the Github issue in [1].
>
>
>
> - What's next?
>
> There are several more things to be done:
>
> 1. We are adding more comprehensive support for GPU versions for different
> CUDA versions.
>
> 2. We are adding more tests on more platforms. We are currently examining
> the MXNet's Jenkins CI solution for supporting more platforms.
>
> 3. As we recognize that the build logic benefits the community, we plan to
> open source the build scripts in the mxnet main repo. See progress at [5].
>
>
>
> Qing Lan, Zach Kimberg, Sheng Zha, and I worked together to make this
> happen. Thanks to Sheng Zha for sharing the pip build logic, and for
> building the automated publishing pipelines. Special thanks to Qing and
> Zach for sharing their expertise in Scala with Sheng and guiding and
> supporting him locally for this milestone.
>
>
>
> [1] https://github.com/apache/incubator-mxnet/issues/8671
>
> [2]
>
> https://github.com/apache/incubator-mxnet/blob/master/scala-package/dev/compile-mxnet-backend.sh#L59-L105
>
> [3]
>
> https://repository.apache.org/#nexus-search;gav~org.apache.mxnet~~1.3.1-SNAPSHOT~~
>
> [4] https://maven.apache.org/repository-management.html
>
> [5] https://github.com/apache/incubator-mxnet/projects/13
>

Re: [DISCUSS] - Revisions to Committer Criteria

[Carin Meier]

Thanks Jason for the suggestion.

I added this to the document to call it out:

In particular, code reviews are encouraged as good initial contributions to
gain understanding of the code base as well as the bar of quality that is
required to merge the code. The PPMC strives to actively identify current
reviewers for committer consideration.

Please feel free to provide feedback and edits on it.

Best,
Carin

On Mon, Oct 29, 2018 at 9:54 AM Jason Dai  wrote:

> Given the recent discussions around code review, I think it makes sense to
> call out the importance of code review contributions for the committer
> criteria.
>
> Thanks,
> -Jason
>
> On Mon, Oct 29, 2018 at 11:12 AM Naveen Swamy  wrote:
>
> > I added clarifying sections to explicitly call out committers/PMC
> > privileges. Please review.
> >
> > Pasting here for convenience
> > Committer Privileges
> >
> >- Committers have write access to the code repository.
> >- Committers have an @apache.org email address.
> >- Committers can make short-term decisions for the project, approving
> >and merging pull requests.
> >- Committer Vote is *NOT* considered *binding* thus the vote you cast
> do
> >not have *Veto* on issues that require consensus.
> >- Committer's can request changes on Pull Requests but it does not
> >constitute Veto, PMC can agree to approve or reject requested changes.
> >
> > PMC Privileges
> >
> >- PMC makes the long-term decisions with regard to the project.
> >- PMC members have write access to the code repository.
> >- PMC members have @apache.org email address.
> >- PMC has access to private@ email list
> >- PMC has the right to vote for the community-related decisions, PMC
> >Votes are *binding*.
> >- PMC has the right to propose active users for committership.
> >- PMC must vote on any formal release of the project's software
> product.
> >
> >
> > All, I suggest you review the proposal and if there is any concern please
> > voice it here before this goes out for voting.
> >
> >
> > On Sun, Oct 28, 2018 at 8:04 AM Carin Meier 
> wrote:
> >
> > > I plan to start a vote on the adopting
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > > to
> > > replace our current document
> > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > > tomorrow
> > > (Monday).
> > >
> > > - Carin
> > >
> > > On Thu, Oct 25, 2018 at 8:32 AM Carin Meier 
> > wrote:
> > >
> > > > Thanks for publishing the notes and also thanks everyone for
> providing
> > > > valuable feedback and discussion.
> > > >
> > > > I encourage everyone that has ideas for improvement to the document
> to
> > > > feel free to edit and revise. If you need a login to the wiki, please
> > > just
> > > > ask.
> > > >
> > > > Also, while editing, please keep in mind that the intent is to have a
> > > vote
> > > > on adopting the new
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > > > to replace our current document
> > > >
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > > > before a vote on separating levels of committer and PPMC as a
> process.
> > > So,
> > > > if possible, adopting wording that would work in either outcome of
> that
> > > > vote.
> > > >
> > > > On the subject of voting, I was thinking of starting a vote on
> Friday,
> > > but
> > > > will delay that until the active discussions and revisions are
> > complete.
> > > >
> > > > Best,
> > > > Carin
> > > >
> > > > On Thu, Oct 25, 2018 at 6:39 AM Pedro Larroy <
> > > pedro.larroy.li...@gmail.com>
> > > > wrote:
> > > >
> > > >> This is the first hangout that I was able to attend, I liked the
> > format
> > > >> and
> > > >> found them valuable. Thanks for organizing and publishing the notes.
> > > >> Looking forward to the next one.
> > > >>
> > > >> Pedro
> > > >>
> > > >> On Thu, Oct 25, 2018 at 6:44 AM Steffen Rochel

Re: [DISCUSS] - Revisions to Committer Criteria

[Carin Meier]

I plan to start a vote on the adopting
https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
to
replace our current document
https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer tomorrow
(Monday).

- Carin

On Thu, Oct 25, 2018 at 8:32 AM Carin Meier  wrote:

> Thanks for publishing the notes and also thanks everyone for providing
> valuable feedback and discussion.
>
> I encourage everyone that has ideas for improvement to the document to
> feel free to edit and revise. If you need a login to the wiki, please just
> ask.
>
> Also, while editing, please keep in mind that the intent is to have a vote
> on adopting the new
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> to replace our current document
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> before a vote on separating levels of committer and PPMC as a process. So,
> if possible, adopting wording that would work in either outcome of that
> vote.
>
> On the subject of voting, I was thinking of starting a vote on Friday, but
> will delay that until the active discussions and revisions are complete.
>
> Best,
> Carin
>
> On Thu, Oct 25, 2018 at 6:39 AM Pedro Larroy 
> wrote:
>
>> This is the first hangout that I was able to attend, I liked the format
>> and
>> found them valuable. Thanks for organizing and publishing the notes.
>> Looking forward to the next one.
>>
>> Pedro
>>
>> On Thu, Oct 25, 2018 at 6:44 AM Steffen Rochel 
>> wrote:
>>
>> > Carin - please see
>> >
>> >
>> https://cwiki.apache.org/confluence/display/MXNET/Hangout+October+24th+2018+8am+and+5pm+PDT
>> > :
>> > Discussion about committer proposal:
>> >
>> >- Proposal default should be to have separation between committer and
>> >PPMC election
>> >- Criteria are vague, should we add some example persona?
>> >- Spell out privileges of committer and PPMC member
>> >
>> >
>> > Note: I update the project proposal to address first bullet.
>> >
>> > Steffen
>> >
>> >
>> > On Wed, Oct 24, 2018 at 11:29 AM Carin Meier 
>> wrote:
>> >
>> > > A request to whoever is taking notes at the MXNet Hangouts that are
>> > > occurring today. Could you please recap feedback from the meeting in
>> > > regards to document revisions here for everyone? I would like to
>> attend
>> > the
>> > > session later today, but may not due to family obligations.
>> > >
>> > > Thanks!
>> > > Carin
>> > >
>> > > On Tue, Oct 23, 2018 at 2:24 PM Steffen Rochel <
>> steffenroc...@gmail.com>
>> > > wrote:
>> > >
>> > > > Carin - I got feedback on my proposal and made changes. I
>> incorporated
>> > > > Tianqi's suggesiton that we should strive to nominate committer/PPMC
>> > > > candidates from outside ones own organization. It should not be
>> > > considered
>> > > > as a hard rule, but recommendation.
>> > > >
>> > > > Steffen
>> > > >
>> > > > On Mon, Oct 22, 2018 at 2:18 PM Carin Meier 
>> > > wrote:
>> > > >
>> > > > > Thanks Steffen helping draft up the proposal for Committer and
>> PPMC
>> > > > > guidelines.
>> > > > >
>> > > > > Please everyone review and provide feedback
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+(incubating)+Committer+and+PPMC+Member+Proposal
>> > > > > .
>> > > > >
>> > > > > I plan to start a vote on this Friday if the discussions/revisions
>> > are
>> > > > > complete.
>> > > > >
>> > > > > - Carin
>> > > > >
>> > > > > On Fri, Oct 19, 2018 at 12:03 PM Carin Meier <
>> carinme...@gmail.com>
>> > > > wrote:
>> > > > >
>> > > > > > Great!
>> > > > > >
>> > > > > > I started a rough draft for collaboration at
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/disp

Re: [DISCUSS] - Revisions to Committer Criteria

[Carin Meier]

Thanks for publishing the notes and also thanks everyone for providing
valuable feedback and discussion.

I encourage everyone that has ideas for improvement to the document to feel
free to edit and revise. If you need a login to the wiki, please just ask.

Also, while editing, please keep in mind that the intent is to have a vote
on adopting the new
https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
to replace our current document
https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
before a vote on separating levels of committer and PPMC as a process. So,
if possible, adopting wording that would work in either outcome of that
vote.

On the subject of voting, I was thinking of starting a vote on Friday, but
will delay that until the active discussions and revisions are complete.

Best,
Carin

On Thu, Oct 25, 2018 at 6:39 AM Pedro Larroy 
wrote:

> This is the first hangout that I was able to attend, I liked the format and
> found them valuable. Thanks for organizing and publishing the notes.
> Looking forward to the next one.
>
> Pedro
>
> On Thu, Oct 25, 2018 at 6:44 AM Steffen Rochel 
> wrote:
>
> > Carin - please see
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Hangout+October+24th+2018+8am+and+5pm+PDT
> > :
> > Discussion about committer proposal:
> >
> >- Proposal default should be to have separation between committer and
> >PPMC election
> >- Criteria are vague, should we add some example persona?
> >- Spell out privileges of committer and PPMC member
> >
> >
> > Note: I update the project proposal to address first bullet.
> >
> > Steffen
> >
> >
> > On Wed, Oct 24, 2018 at 11:29 AM Carin Meier 
> wrote:
> >
> > > A request to whoever is taking notes at the MXNet Hangouts that are
> > > occurring today. Could you please recap feedback from the meeting in
> > > regards to document revisions here for everyone? I would like to attend
> > the
> > > session later today, but may not due to family obligations.
> > >
> > > Thanks!
> > > Carin
> > >
> > > On Tue, Oct 23, 2018 at 2:24 PM Steffen Rochel <
> steffenroc...@gmail.com>
> > > wrote:
> > >
> > > > Carin - I got feedback on my proposal and made changes. I
> incorporated
> > > > Tianqi's suggesiton that we should strive to nominate committer/PPMC
> > > > candidates from outside ones own organization. It should not be
> > > considered
> > > > as a hard rule, but recommendation.
> > > >
> > > > Steffen
> > > >
> > > > On Mon, Oct 22, 2018 at 2:18 PM Carin Meier 
> > > wrote:
> > > >
> > > > > Thanks Steffen helping draft up the proposal for Committer and PPMC
> > > > > guidelines.
> > > > >
> > > > > Please everyone review and provide feedback
> > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+(incubating)+Committer+and+PPMC+Member+Proposal
> > > > > .
> > > > >
> > > > > I plan to start a vote on this Friday if the discussions/revisions
> > are
> > > > > complete.
> > > > >
> > > > > - Carin
> > > > >
> > > > > On Fri, Oct 19, 2018 at 12:03 PM Carin Meier  >
> > > > wrote:
> > > > >
> > > > > > Great!
> > > > > >
> > > > > > I started a rough draft for collaboration at
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+a+Committer+Proposal
> > > > > > .
> > > > > >
> > > > > > Everyone feel free to enhance and provide feedback.
> > > > > >
> > > > > > - Carin
> > > > > >
> > > > > > On Fri, Oct 19, 2018 at 10:55 AM Steffen Rochel <
> > > > steffenroc...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> +1, great suggestion, thanks Carin!
> > > > > >> I'm willing to collaborate to create a draft proposal.
> > > > > >> Steffen
> > > > > >>
> > > > > >> On Fri, Oct 19, 2018 at 5:35 AM Carin Meier <
> carinme...@gmail.com
> > >
&g

Re: [Discussion] PMC and Committer Courtesy: Only Propose Candidate in a Different Organization

[Carin Meier]

I should clarify - parts were removed and parts were added :)
I'm not sure if this is exactly that Tianqi had in mind or not. But the
document is open to feedback. These threads are getting a bit confused. So
if you are going to discuss the document - please prefer the [DISCUSS] -
Revisions to Committer Criteria thread.

Thanks,
Carin

On Wed, Oct 24, 2018 at 5:05 PM Carin Meier  wrote:

> I think it was removed from the document by Steffen from feedback
> https://lists.apache.org/thread.html/4ed84034f9cac4cacae865dd5b5699aa1f9d650c0feee37072df41fa@%3Cdev.mxnet.apache.org%3E
>
> The diff is here
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=95652053=4=3
>
> On Wed, Oct 24, 2018 at 4:29 PM Jim Jagielski  wrote:
>
>> Neither can I.
>>
>> > On Oct 22, 2018, at 12:19 AM, Naveen Swamy  wrote:
>> >
>> > this suggestion looks like it is putting the onus on contributors to
>> > collaborate with contributors outside their org to get nominated to be
>> > committer or a PMC of this project.
>> > Every organization has its own business goals, on the way to meet their
>> > objectives if their employees happen to be great contributors to this
>> > project, I would expect PMC members(wearing their Apache hat) to
>> recognize
>> > them and give them a greater role in the project.
>> > I would assume the responsibility of increasing the diversity is solely
>> > upon the PMC members, the PMC should look ways to evangelize the
>> project,
>> > mentor new contributors, nominate and make them a part of the project's
>> > journey.
>> > I do agree that we have to increase the diversity and suggest to explore
>> > different ways( for example collaborate with other successful Open
>> source
>> > projects to get their members excited about MXNet).
>> >
>> > Guideline or not, I cannot agree to this in principle.
>> > -1
>> >
>> >
>> > On Sun, Oct 21, 2018 at 8:22 PM Tianqi Chen 
>> > wrote:
>> >
>> >>>
>> >>> Many potential committers and
>> >>> PMC won’t interact with the non-Amazonians at all (since there are so
>> >> few),
>> >>> so they’d be relegated to obscurity and hopelessness by default.
>> >>>
>> >>
>> >> If potential contributors do not comes from Amazon, then the Amazonian
>> PMC
>> >> can nominate them :)  If the potential contributors does comes from
>> Amazon,
>> >> then it is not a bad thing to interact with bigger part of the
>> community. I
>> >> can expect that as more non-Amazonian contributors get nonimated, this
>> >> would make the process more healthy.
>> >>
>> >> Like neural networks, any guideline can be played in adverserial
>> fashion
>> >> (e.g. in the case of the gray areas). I think having a goodwill to
>> push the
>> >> guideline will understandably make people to work together.
>> >>
>> >> Afterall, this is an Apache project that should goes beyond a single
>> >> company
>> >>
>> >> Tianqi
>> >>
>> >>>
>> >>>
>> >>>
>> >>> On Sun, Oct 21, 2018 at 5:06 PM Steffen Rochel <
>> steffenroc...@gmail.com>
>> >>> wrote:
>> >>>
>> >>>> Hi Tianqi -
>> >>>> +1 . I like the idea to grow diversity at the project and encourage
>> >>>> communication beyond people sitting next to each other. I also
>> support
>> >>> the
>> >>>> way you described as guideline, not has a hard rule. I think it is
>> >>>> important we focus on merit and contributions when evaluating nominee
>> >> for
>> >>>> committer and PPMC.
>> >>>>
>> >>>> Carin started a draft document for revised criteria for committer and
>> >>> PPMC
>> >>>> membership
>> >>>> <
>> >>>>
>> >>>
>> >>
>> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
>> >>>>> .
>> >>>> I suggest to contribute, provide feedback and suggestion including
>> your
>> >>>> proposal.
>> >>>>
>> >>>> Steffen
>> >>>>
>> >>>> On Sun, Oct 21, 2018 at 10:22 AM Tianqi Chen 
>> >> wrote: