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

2019-07-03 Thread 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

2019-05-23 Thread 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)

2019-05-21 Thread 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

2019-05-21 Thread 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

2019-05-09 Thread 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

2019-05-01 Thread 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

2019-04-29 Thread 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

2019-04-26 Thread 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?

2019-04-20 Thread 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

2019-04-16 Thread 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

2019-03-31 Thread 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

2019-03-29 Thread 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

2019-03-29 Thread 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

2019-03-25 Thread 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

2019-03-24 Thread 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

2019-03-08 Thread 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

2019-03-08 Thread 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

2019-03-02 Thread 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

2019-02-25 Thread 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

2019-02-24 Thread 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

2019-02-24 Thread 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

2019-02-24 Thread 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

2019-02-24 Thread 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

2019-02-24 Thread 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

2019-02-24 Thread 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

2019-02-24 Thread 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

2019-02-24 Thread 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

2019-02-24 Thread 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

2019-02-17 Thread 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

2019-02-15 Thread 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

2019-02-11 Thread 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

2019-02-11 Thread 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?

2019-02-11 Thread 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

2019-02-06 Thread 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

2019-01-29 Thread 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

2019-01-29 Thread 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

2019-01-23 Thread 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

2019-01-22 Thread 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

2019-01-21 Thread 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

2019-01-20 Thread 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

2019-01-19 Thread 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

2019-01-19 Thread 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

2019-01-18 Thread 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

2019-01-18 Thread 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

2019-01-16 Thread 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

2019-01-16 Thread 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

2019-01-14 Thread 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

2019-01-12 Thread 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
> >
>


Question about notification on nightly test failures

2019-01-12 Thread Carin Meier
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


[Announcement] New Committer - Roshani Nagmote

2019-01-08 Thread Carin Meier
Please join me in welcoming Roshani Nagmote as a new committer.

She has been active in the project for quite some time. She has managed the
1.3.0 release as well as being involved various features including the Java
API and ONNX operators.

We are excited to have her onboard as a committer.

 Github Activity
https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+involves%3ARoshrini
+

Confluence
https://cwiki.apache.org/confluence/users/viewuserprofile.action?username=roshrini


Re: Julia Package Release Process

2019-01-07 Thread 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

2019-01-05 Thread 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

2019-01-05 Thread 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

2018-12-16 Thread 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

2018-12-14 Thread 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

2018-12-14 Thread 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

2018-12-12 Thread 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?

2018-11-20 Thread 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?

2018-11-20 Thread 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

2018-11-13 Thread 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
>


[VOTE][RESULTS] Separating PMC and Committership

2018-11-09 Thread Carin Meier
The vote passed to separate PMC and Committership -
https://lists.apache.org/thread.html/6c6b41549724caaa2304855564ef851b0e77cf5a07a2f86ba9879c43@%3Cdev.mxnet.apache.org%3E

*+1 Binding*
Tianqi Chen
Haibin Lin
Chris Oliver
Sebastian Schelter
Yuan Tang

*+1 Non Binding*
Thomas Delteil
Qin Lan
Kellen Sunderland

Thanks to everyone involved.

Best,
Carin


Re: [VOTE] Separating PMC and Committership

2018-11-08 Thread 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

2018-11-05 Thread 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

2018-11-04 Thread 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

2018-11-02 Thread 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

2018-11-02 Thread 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

2018-11-01 Thread 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

2018-10-30 Thread 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

2018-10-30 Thread Carin Meier
>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

2018-10-29 Thread 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

2018-10-29 Thread 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

2018-10-29 Thread 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

2018-10-29 Thread 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

2018-10-29 Thread 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

2018-10-28 Thread 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

2018-10-25 Thread 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

2018-10-24 Thread 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:

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

2018-10-24 Thread Carin Meier
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:
> 
> > Dear MXNet Community:
> >
> > There has been a great discussion going on in terms of
> > PMC/Committer Criteria.  As a community move forward, it is important
> >>> to
> > make the community inclusive to everyone and encourage folks to work
> > together.
> >
> > I want to propose the following proposal courtesy: when a PMC
> >> proposes
> >>> a
> > committer/PMC member, for courtesy of the community, she/he should
> >> only
> > propose a person from a different organization(company).
> >
> > The idea behind that is that the Apache project goes beyond a single
> > organization, it is important to recognize others, including those
> >>> from a
> > different organization in the community, and get your merit being
> > recognized by others.
> >
> > Admittedly, this would also give more "power" to the PMC members from
> > minority organizations -- which I think is a good thing. This might
> >>> also
> > encourage everyone to work together and talk to folks who are beyond
> >>> your
> > next door
> >
> > Tianqi
> >
> 
> >>>
> >>
>
>


Re: [DISCUSS] - Revisions to Committer Criteria

2018-10-24 Thread Carin Meier
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 
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 
> > wrote:
> > >>
> > >> > Background:
> > >> >
> > >> > There is a desire to increase the committer pool and grow the
> > community.
> > >> > This thread is to discuss the possibility of revision the current
> > >> committer
> > >> > criteria in light of the following goals:
> > >> >
> > >> > - Make it easier to newcomers to be committers
> > >> > - Recognize non-code contributions as paths to committership
> > >> > - Open the door to separating levels of committer and PMC (discussed
> > in
> > >> > another thread)
> > >> >
> > >> > Current State:
> > >> >
> > >> > The current committer criteria is here
> > >> >
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > >> as
> > >> > is modeled after the Hadoop committer criteria
> > >> > https://hadoop.apache.org/committer_criteria.html
> > >> >
> > >> > Proposal:
> > >> >
> > >> > Model the MXNet path to committership and PMC after the Apache Beam
> > >> project
> > >> > https://beam.apache.org/contribute/become-a-committer/
> > >> >
> > >> > Short quote from page:
> > >> >   =
> > >> > An Apache Beam committer…
> > >> > <
> > >> >
> > >>
> >
> https://beam.apache.org/contribute/become-a-committer/#an-apache-beam-committer
> > >> > >
> > >> >
> > >> >- Takes many forms
> > >> ><
> > >> >
> > https://beam.apache.org/contribute/become-a-committer/#takes-many-forms
> > >> >
> > >> >- Knows, upholds, and reinforces the Apache Software Foundation
> > code
> > >> of
> > >> >conduct
> > >> ><
> > >> >
> > >>
> >
> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-apache-software-foundation-code-of-conduct
> > >> > >
> > >> >- Knows, upholds, and reinforces the responsibilities of an
> Apache
> > >> >Software Foundation committer
> > >> ><
> > >> >
> > >>
> >
> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-responsibilities-of-an-apache-software-foundation-committer
> > >> > >
> > >> >- Knows, upholds, and reinforces the Beam community’s practices
> > >> ><
> > >> >
> > >>
> >
> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-beam-communitys-practices
> > >> > >
> > >> >- =
> > >> ><
> > >> >
> > >>
> >
> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-beam-communitys-practices
> > >> > >
> > >> >
> > >> >
> > >> > I believe if we merge our current committer criteria with this model
> > it
> > >> > will open  the path to committership to a wider pool, acknowledge
> that
> > >> > there are multiple paths, and reinforce the ASF values and
> > >> > responsibilities.
> > >> >
> > >> > The Beam model does not explicitly address a PMC level but we could
> > add
> > >> it
> > >> > in in the same spirit of reinforcing the ASF responsibilities and
> > >> values of
> > >> > this level.
> > >> >
> > >> > Looking forward to feedback about this possible direction. If the
> > >> community
> > >> > is interested looking more into this direction I would be happy to
> > >> create
> > >> > of first draft of something more concrete to look at - (or if
> someone
> > >> else
> > >> > wants to take a crack at it too that would be great)
> > >> >
> > >> > - Carin
> > >> >
> > >>
> > >
> >
>


Re: [DISCUSS] - Revisions to Committer Criteria

2018-10-22 Thread Carin Meier
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 
> 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  wrote:
>>
>> > Background:
>> >
>> > There is a desire to increase the committer pool and grow the community.
>> > This thread is to discuss the possibility of revision the current
>> committer
>> > criteria in light of the following goals:
>> >
>> > - Make it easier to newcomers to be committers
>> > - Recognize non-code contributions as paths to committership
>> > - Open the door to separating levels of committer and PMC (discussed in
>> > another thread)
>> >
>> > Current State:
>> >
>> > The current committer criteria is here
>> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>> as
>> > is modeled after the Hadoop committer criteria
>> > https://hadoop.apache.org/committer_criteria.html
>> >
>> > Proposal:
>> >
>> > Model the MXNet path to committership and PMC after the Apache Beam
>> project
>> > https://beam.apache.org/contribute/become-a-committer/
>> >
>> > Short quote from page:
>> >   =
>> > An Apache Beam committer…
>> > <
>> >
>> https://beam.apache.org/contribute/become-a-committer/#an-apache-beam-committer
>> > >
>> >
>> >- Takes many forms
>> ><
>> > https://beam.apache.org/contribute/become-a-committer/#takes-many-forms
>> >
>> >- Knows, upholds, and reinforces the Apache Software Foundation code
>> of
>> >conduct
>> ><
>> >
>> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-apache-software-foundation-code-of-conduct
>> > >
>> >- Knows, upholds, and reinforces the responsibilities of an Apache
>> >Software Foundation committer
>> ><
>> >
>> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-responsibilities-of-an-apache-software-foundation-committer
>> > >
>> >- Knows, upholds, and reinforces the Beam community’s practices
>> ><
>> >
>> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-beam-communitys-practices
>> > >
>> >- =
>> ><
>> >
>> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-beam-communitys-practices
>> > >
>> >
>> >
>> > I believe if we merge our current committer criteria with this model it
>> > will open  the path to committership to a wider pool, acknowledge that
>> > there are multiple paths, and reinforce the ASF values and
>> > responsibilities.
>> >
>> > The Beam model does not explicitly address a PMC level but we could add
>> it
>> > in in the same spirit of reinforcing the ASF responsibilities and
>> values of
>> > this level.
>> >
>> > Looking forward to feedback about this possible direction. If the
>> community
>> > is interested looking more into this direction I would be happy to
>> create
>> > of first draft of something more concrete to look at - (or if someone
>> else
>> > wants to take a crack at it too that would be great)
>> >
>> > - Carin
>> >
>>
>


Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

2018-10-19 Thread Carin Meier
+1 Great idea. Adding a name to the contributor list is a good idea. Also,
I've found that thanking the person for the review on the PR is another way
to express gratitude for their time and effort.

On Fri, Oct 19, 2018 at 2:51 PM Tianqi Chen  wrote:

> Dear MXNet Community:
>
> There is a great discussion going on in terms of lowering the barrier of
> entries and encourage more contribution to the project.  One of the general
> goals is to encourage a broader pool of contributions. I want to make the
> following proposal:
>
> Besides Committers and PMC, let us also recognize Reviewers in the
> community.  This is a "pseudo role" as there is no such official role in
> Apache. But I want to explore the possibility of recognizing active
> reviewers for example, by adding a list of names in the contributor list.
> In general, I find it is really helpful to have more code reviews.
> Recognizing good reviewers early enables us to find committer candidates,
> and encourage them to contribute and understand what is the bar of code
> quality that is required to merge the code.
>
> This can provide the community with more evidence when recruiting new
> committers. After all the write access of committership is about to the
> code and understand the consequence of the responsibility -- which is
> usually can be found in high-quality review history.
>
> Please let me know what you think.
>
> Tianqi
>


Re: [DISCUSS] - Revisions to Committer Criteria

2018-10-19 Thread Carin Meier
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 
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  wrote:
>
> > Background:
> >
> > There is a desire to increase the committer pool and grow the community.
> > This thread is to discuss the possibility of revision the current
> committer
> > criteria in light of the following goals:
> >
> > - Make it easier to newcomers to be committers
> > - Recognize non-code contributions as paths to committership
> > - Open the door to separating levels of committer and PMC (discussed in
> > another thread)
> >
> > Current State:
> >
> > The current committer criteria is here
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> as
> > is modeled after the Hadoop committer criteria
> > https://hadoop.apache.org/committer_criteria.html
> >
> > Proposal:
> >
> > Model the MXNet path to committership and PMC after the Apache Beam
> project
> > https://beam.apache.org/contribute/become-a-committer/
> >
> > Short quote from page:
> >   =
> > An Apache Beam committer…
> > <
> >
> https://beam.apache.org/contribute/become-a-committer/#an-apache-beam-committer
> > >
> >
> >- Takes many forms
> ><
> > https://beam.apache.org/contribute/become-a-committer/#takes-many-forms>
> >- Knows, upholds, and reinforces the Apache Software Foundation code
> of
> >conduct
> ><
> >
> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-apache-software-foundation-code-of-conduct
> > >
> >- Knows, upholds, and reinforces the responsibilities of an Apache
> >Software Foundation committer
> ><
> >
> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-responsibilities-of-an-apache-software-foundation-committer
> > >
> >- Knows, upholds, and reinforces the Beam community’s practices
> ><
> >
> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-beam-communitys-practices
> > >
> >- =
> ><
> >
> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-beam-communitys-practices
> > >
> >
> >
> > I believe if we merge our current committer criteria with this model it
> > will open  the path to committership to a wider pool, acknowledge that
> > there are multiple paths, and reinforce the ASF values and
> > responsibilities.
> >
> > The Beam model does not explicitly address a PMC level but we could add
> it
> > in in the same spirit of reinforcing the ASF responsibilities and values
> of
> > this level.
> >
> > Looking forward to feedback about this possible direction. If the
> community
> > is interested looking more into this direction I would be happy to create
> > of first draft of something more concrete to look at - (or if someone
> else
> > wants to take a crack at it too that would be great)
> >
> > - Carin
> >
>


[DISCUSS] - Revisions to Committer Criteria

2018-10-19 Thread Carin Meier
Background:

There is a desire to increase the committer pool and grow the community.
This thread is to discuss the possibility of revision the current committer
criteria in light of the following goals:

- Make it easier to newcomers to be committers
- Recognize non-code contributions as paths to committership
- Open the door to separating levels of committer and PMC (discussed in
another thread)

Current State:

The current committer criteria is here
https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer as
is modeled after the Hadoop committer criteria
https://hadoop.apache.org/committer_criteria.html

Proposal:

Model the MXNet path to committership and PMC after the Apache Beam project
https://beam.apache.org/contribute/become-a-committer/

Short quote from page:
  =
An Apache Beam committer…


   - Takes many forms
   
   - Knows, upholds, and reinforces the Apache Software Foundation code of
   conduct
   

   - Knows, upholds, and reinforces the responsibilities of an Apache
   Software Foundation committer
   

   - Knows, upholds, and reinforces the Beam community’s practices
   

   - =
   



I believe if we merge our current committer criteria with this model it
will open  the path to committership to a wider pool, acknowledge that
there are multiple paths, and reinforce the ASF values and responsibilities.

The Beam model does not explicitly address a PMC level but we could add it
in in the same spirit of reinforcing the ASF responsibilities and values of
this level.

Looking forward to feedback about this possible direction. If the community
is interested looking more into this direction I would be happy to create
of first draft of something more concrete to look at - (or if someone else
wants to take a crack at it too that would be great)

- Carin


Re: [Discussion] Separating PMC and Committership

2018-10-18 Thread Carin Meier
Thanks Micheal for making the process clearer to me. It helps quite a bit.

Also thanks to Chris and Steffen for your clarification and input.

I think there are two issues that are intermingled in considering this. One
relates to separating levels of committer and PMC member. The other, as
Steffen pointed out, relates to the criteria which we use to consider
people for these levels of membership. I would propose that to make it
easier to achieve consensus, we consider them each as their own proposal.

The proposal of separating levels of committer and PMC member can be
considered on the Apache definitions of rights and responsibilities here
https://www.apache.org/foundation/how-it-works.html#roles: Since the PMC
member has more rights and responsibilities than a committer, I think it
implies a stricter criteria, (although it would be unspecified in the
proposal).

The proposal of redefining our project's criteria in respect to how we
consider nomination to those roles could be a separate discussion and vote
since there are other issues that we might want to tackle such as inclusion
of non-code contributions and general alignment to the Apache definitions.

We can of course choose to tackle the proposal of redefining the criteria
first or do the separation of levels first since the discussion is already
in progress.

Thoughts?

- Carin






On Thu, Oct 18, 2018 at 2:04 AM Steffen Rochel 
wrote:

> Haibin's proposed "For active contributors we first invite them to become
> our committers. Later on as they make significant contribution, we can
> invite them to PMC."
> Several people raised the question what defines "active contributors" and
> "make significant contribution". In my view the discussion has not answered
> the questions and it is not clear to me what changes are proposed to
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer .
> I'm making the assumption that the proposal is to simplify the path for
> becoming a committer to grow the committer community. So far I have not
> heard what changes or simplifications are proposed. Without a change I fail
> to see the benefit of this proposal to increase the number of committers.
> I agree that the path from committer to PMC member should be clarified as
> well and suggest to align with expectations and responsibilities of PMC
> members.
> I'm also under the assumption that the proposal only applies for future
> committers and PMC members, not for existing PMC members and this
> assumption should be clarified.
>
> Steffen
>
> On Wed, Oct 17, 2018 at 4:29 PM Chris Olivier 
> wrote:
>
> > I believe the assumption has always been that current PMC members will
> > remain PMC members.
> >
> > On Wed, Oct 17, 2018 at 3:51 PM Michael Wall  wrote:
> >
> > > I too think separating committers from PMC is a good idea for your
> > project
> > > given the desire to grow committers and the concerns I have seen trying
> > to
> > > add new committers.  I saw at least one other mentor, Jim on this
> thread
> > > too.
> > >
> > > Is the plan to leave all current PMC members in the PMC?  If that is
> not
> > > the plan, perhaps more discussion is required before moving on.
> > >
> > > Assuming you feel the discussion is done, someone needs to start a
> vote.
> > > This would be a procedural change as outlined on
> > > https://www.apache.org/foundation/voting.html
> > >
> > > If I were doing it, I would announce on this thread I am starting a
> vote
> > on
> > > this matter tomorrow or some specified time.  I might even outline what
> > the
> > > vote will be.  This give people a chance to speak up if they think more
> > > discussion is needed.  Assuming no more discussion, start a [VOTE]
> thread
> > > on the dev list.
> > >
> > > I am used to seeing [VOTE] and [DISCUSS] in the subject line of such
> > emails
> > > but I didn't find any official guidance on that.  Maybe it is a project
> > by
> > > project decision, I did find
> > >
> https://cwiki.apache.org/confluence/display/EDGENT/Sample+process+emails
> > .
> > > I totally parsed right over the [Discussion] in the subject this thread
> > but
> > > I'll be on the look out for it in the future.
> > >
> > > Thanks
> > >
> > > Mike
> > >
> > > On Wed, Oct 17, 2018 at 6:05 PM Carin Meier 
> > wrote:
> > >
> > > > Let me rephrase the question.
> > > >
> > > > Since I'm new to the committer/PMC process, I wondering what the next
> > > step
> > > > is in a proposed cha

Re: [Discussion] Separating PMC and Committership

2018-10-17 Thread Carin Meier
Let me rephrase the question.

Since I'm new to the committer/PMC process, I wondering what the next step
is in a proposed change of process like this.

If we gauge that there is a significant enough interest do we propose a
vote? Is there enough interest and information to have a vote in this case?

(Anyone feel free to answer the question - mentor or not :) )

- Carin

On Tue, Oct 16, 2018 at 7:48 PM Carin Meier  wrote:

> This has been a very interesting discussion and I think it underlined a
> desire to increase the committer pool and community for the project. I'm
> wondering now what the next steps would look like?
>
> Do any mentors have any advice on how to proceed?
>
> - Carin
>
> On Thu, Oct 11, 2018 at 1:23 PM Jim Jagielski  wrote:
>
>> In my experience, and in my opinion, it makes sense to distinguish and
>> differentiate between a committer and a PMC member. The latter shows just a
>> bit more "investment" in the project and has obtained a bit more merit due
>> to their continued efforts.
>>
>> Of course, what we also need is some public governance model that shows
>> what these levels are, what they mean and how to obtain them. The following
>> is the normal setup for Apache projects:
>>
>> https://www.apache.org/foundation/how-it-works.html#roles
>>
>> The nice this is that this also allows for a very low-bar-to-entry for
>> committer-ship while still maintain a somewhat higher bar for the PPMC,
>> which is great for community building.
>>
>> > On 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 

Re: [Discussion] Separating PMC and Committership

2018-10-16 Thread Carin Meier
This has been a very interesting discussion and I think it underlined a
desire to increase the committer pool and community for the project. I'm
wondering now what the next steps would look like?

Do any mentors have any advice on how to proceed?

- Carin

On Thu, Oct 11, 2018 at 1:23 PM Jim Jagielski  wrote:

> In my experience, and in my opinion, it makes sense to distinguish and
> differentiate between a committer and a PMC member. The latter shows just a
> bit more "investment" in the project and has obtained a bit more merit due
> to their continued efforts.
>
> Of course, what we also need is some public governance model that shows
> what these levels are, what they mean and how to obtain them. The following
> is the normal setup for Apache projects:
>
> https://www.apache.org/foundation/how-it-works.html#roles
>
> The nice this is that this also allows for a very low-bar-to-entry for
> committer-ship while still maintain a somewhat higher bar for the PPMC,
> which is great for community building.
>
> > On 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 

Re: Develop a video course on Gluon with Packt

2018-10-14 Thread Carin Meier
Thanks for thinking of me but I don't have time for a project like that.

- Carin

On Sun, Oct 14, 2018 at 7:33 PM Mandar Raorane  wrote:

> Hello Team,
>
>
> I am Mandar Raorane, a Video Acquisition Editor at Packt Publishing. Packt
> has been in IT publishing for over a decade now and we have been providing
> our viewers with practical, friendly screencast tutorials on interesting
> technologies.
>
> Hyunsu Cho shared your email Id's with me so that we could discuss this
> collaboration on developing a video course on Gluon. The course is titled
> "Getting Started with Gluon for Deep Learning"
>
> Would you be interested in developing this course with us?  I will provide
> more details about the process and payments later.
>
> Looking forward to hearing from you and for a successful collaboration.
>
>
> Have a nice weekend ahead.
>
> [https://s3-eu-west-1.amazonaws.com/email-signature-packt/128x128px.png]
>
>
>
>
>
> Mandar Raorane
>
> Video Acquisition Editor
>
>
>
>  [https://s3-eu-west-1.amazonaws.com/email-signature-packt/ph.png]
>  022-28328148
>
>  [https://s3-eu-west-1.amazonaws.com/email-signature-packt/web.png]
> www.packt.com
>  [https://s3-eu-west-1.amazonaws.com/email-signature-packt/msg.png]
> mand...@packt.com
> [https://s3-eu-west-1.amazonaws.com/email-signature-packt/loc.png]  Plot
> No.103, Arena House, 3rd Floor,12th Road, MIDC, Andheri (E), Mumbai -
> 400093 Mumbai Maharashtra 400093.
>
>
> [https://www.facebook.com/PacktPub/?ref=br_rs]<
> https://www.facebook.com/PacktPub/?ref=br_rs>  [
> https://twitter.com/PacktPub]    [
> https://www.linkedin.com/company/packt-publishing/] <
> https://www.linkedin.com/company/packt-publishing/>   [
> https://www.youtube.com/channel/UC3VydBGBl132baPCLeDspMQ] <
> https://www.youtube.com/channel/UC3VydBGBl132baPCLeDspMQ>
>
>
>
>
>
>
>
> Packt Publishing Private Limited. Registered Address: Plot No.103, Arena
> House, 3rd Floor,12th Road, MIDC, Andheri (E), Mumbai - 400093.
> CIN:U22100MH2005PTC152766
> This E-mail is confidential. It may also be legally privileged. If you are
> not the addressee you may not copy, forward, disclose or use any part of
> it. If you have received this message in error, please delete it and all
> copies from your system and notify the sender immediately by return E-mail.
> Whilst Packt Publishing Ltd take every reasonable precaution to avoid the
> transfer of software viruses or defects that may cause damage to computer
> systems; it is the responsibility of the recipient to ensure that all
> emails and attachments received are free from infection.
> The word 'Packt'® and the Packt logo are registered trademarks which
> belong to Packt Publishing Limited.
>


Re: Which merge option to use on the Import Julia binding PR?

2018-10-04 Thread Carin Meier
Micheal,

Thanks for catching up and helping us with this.
I do see the "view command line instructions". I just assumed that master
was a protected branch and I would not be able to push to it.
Honestly, I'm a bit scared if it isn't :)

What do you suggest? Should I try to merge and push to master?

On Thu, Oct 4, 2018 at 7:19 PM Michael Wall  wrote:

> Just now looking at this.  The button is disabled for merge commit as you
> have mentioned.  Before I go to INFRA, is the command line an option?  Do
> you see "or view command line instructions" beside the green squash and
> merge button?
>
> On Thu, Oct 4, 2018 at 9:09 AM Carin Meier  wrote:
>
> > Thank you Mike!
> >
> > On Thu, Oct 4, 2018 at 8:54 AM Michael Wall  wrote:
> >
> > > Hi Carin,
> > >
> > > I will take a look at this tonight.  I am not tracking everything, so I
> > > want to go back and make sure I understand what is being asked.  Then I
> > am
> > > happy to submit an INFRA ticket.
> > >
> > > Mike
> > >
> > > On Thu, Oct 4, 2018 at 8:36 AM Carin Meier 
> wrote:
> > >
> > > > I just found out that since we are a podling, we should route all our
> > > Infra
> > > > tickets through one of our mentors and link the dev list discussion
> in
> > > > JIRA.
> > > >
> > > > Is there a mentor that is willing to help us navigate this process to
> > get
> > > > the PR merged?
> > > >
> > > > Thanks,
> > > > Carin
> > > >
> > > > On Tue, Oct 2, 2018 at 8:42 AM Carin Meier 
> > wrote:
> > > >
> > > > > Marco - Thanks for the "dry run" idea. It will give everyone a
> clear
> > > idea
> > > > > of the process and what the expected results will look like.
> > > > >
> > > > > - I took my fork of the repo and synced my master branch.
> > > > > - @iblis17 made a copy of the branch of the Julia import PR and
> > > submitted
> > > > > it to my repo
> > > > > - I merged it with the "Merge" option through the web interface.
> > > > >
> > > > > Here is a gif of the process of merging:
> > > > > http://g.recordit.co/DzBcFtnjmV.gif
> > > > > Here is the result of the repo:
> > > > > https://github.com/gigasquid/incubator-mxnet
> > > > >
> > > > > Please everyone take a look and validate that this looks ok.
> > > > >
> > > > > If there are no objections, Marco - could you please take the lead
> in
> > > > > requesting the actions from INFRA?
> > > > >
> > > > > It will be great to *finally* get this PR in  :)
> > > > >
> > > > > Thanks,
> > > > > Carin
> > > > >
> > > > > <
> https://github.com/gigasquid/incubator-mxnet/commits?author=iblis17
> > >
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang 
> > > > wrote:
> > > > >
> > > > >> Sorry, here is the image: https://imgur.com/V5wd2XB
> > > > >>
> > > > >> And here is the github document on the 3 different merge options
> for
> > > the
> > > > >> web UI button:
> > > > >> https://help.github.com/articles/about-pull-request-merges/
> > > > >>
> > > > >> On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
> > > > >>  wrote:
> > > > >>
> > > > >> > Could you upload the picture somewhere please? HTML is being
> > > stripped
> > > > >> out
> > > > >> > on email lists.
> > > > >> >
> > > > >> > Chiyuan Zhang  schrieb am So., 30. Sep.
> 2018,
> > > > 03:44:
> > > > >> >
> > > > >> > > There is an option in the repo settings menu to disable or
> > enable
> > > > >> > > merge-commit for PR, see a screenshot below (from a different
> > > github
> > > > >> > > project):
> > > > >> > >
> > > > >> > > [image: image.png]
> > > > >> > >
> > > > >> > > My guess is that this is disabled for the reason to avoid
> > creating
> > > > >> > > non-linear history

Re: Which merge option to use on the Import Julia binding PR?

2018-10-04 Thread Carin Meier
Thank you Mike!

On Thu, Oct 4, 2018 at 8:54 AM Michael Wall  wrote:

> Hi Carin,
>
> I will take a look at this tonight.  I am not tracking everything, so I
> want to go back and make sure I understand what is being asked.  Then I am
> happy to submit an INFRA ticket.
>
> Mike
>
> On Thu, Oct 4, 2018 at 8:36 AM Carin Meier  wrote:
>
> > I just found out that since we are a podling, we should route all our
> Infra
> > tickets through one of our mentors and link the dev list discussion in
> > JIRA.
> >
> > Is there a mentor that is willing to help us navigate this process to get
> > the PR merged?
> >
> > Thanks,
> > Carin
> >
> > On Tue, Oct 2, 2018 at 8:42 AM Carin Meier  wrote:
> >
> > > Marco - Thanks for the "dry run" idea. It will give everyone a clear
> idea
> > > of the process and what the expected results will look like.
> > >
> > > - I took my fork of the repo and synced my master branch.
> > > - @iblis17 made a copy of the branch of the Julia import PR and
> submitted
> > > it to my repo
> > > - I merged it with the "Merge" option through the web interface.
> > >
> > > Here is a gif of the process of merging:
> > > http://g.recordit.co/DzBcFtnjmV.gif
> > > Here is the result of the repo:
> > > https://github.com/gigasquid/incubator-mxnet
> > >
> > > Please everyone take a look and validate that this looks ok.
> > >
> > > If there are no objections, Marco - could you please take the lead in
> > > requesting the actions from INFRA?
> > >
> > > It will be great to *finally* get this PR in  :)
> > >
> > > Thanks,
> > > Carin
> > >
> > > <https://github.com/gigasquid/incubator-mxnet/commits?author=iblis17>
> > >
> > >
> > >
> > > On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang 
> > wrote:
> > >
> > >> Sorry, here is the image: https://imgur.com/V5wd2XB
> > >>
> > >> And here is the github document on the 3 different merge options for
> the
> > >> web UI button:
> > >> https://help.github.com/articles/about-pull-request-merges/
> > >>
> > >> On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
> > >>  wrote:
> > >>
> > >> > Could you upload the picture somewhere please? HTML is being
> stripped
> > >> out
> > >> > on email lists.
> > >> >
> > >> > Chiyuan Zhang  schrieb am So., 30. Sep. 2018,
> > 03:44:
> > >> >
> > >> > > There is an option in the repo settings menu to disable or enable
> > >> > > merge-commit for PR, see a screenshot below (from a different
> github
> > >> > > project):
> > >> > >
> > >> > > [image: image.png]
> > >> > >
> > >> > > My guess is that this is disabled for the reason to avoid creating
> > >> > > non-linear history for standard PRs (as oppose to technical
> > problem).
> > >> But
> > >> > > this is only my guess, it would be great if someone could confirm.
> > >> > >
> > >> > > Best,
> > >> > > Chiyuan
> > >> > >
> > >> > > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier  >
> > >> > wrote:
> > >> > >
> > >> > >> I believe so, but if someone wants to confirm it would be great.
> > >> > >> Unfortunately, I just came down with a cold/flu so I will be out
> of
> > >> > >> communication for a bit
> > >> > >>
> > >> > >> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
> > >> > >>  wrote:
> > >> > >>
> > >> > >> > Are we sure that this is due to lacking permissions and not
> > >> because of
> > >> > >> some
> > >> > >> > technical limitation? If we are certain, we can ask out mentors
> > to
> > >> > >> create a
> > >> > >> > ticket with Apache Infra to make that switch.
> > >> > >> >
> > >> > >> > -Marco
> > >> > >> >
> > >> > >> > Carin Meier  schrieb am Sa., 29. Sep.
> > 2018,
> > >> > >> 01:17:
> > >> > >> >
> > >> > >> > > I made a

Re: Which merge option to use on the Import Julia binding PR?

2018-10-04 Thread Carin Meier
I just found out that since we are a podling, we should route all our Infra
tickets through one of our mentors and link the dev list discussion in JIRA.

Is there a mentor that is willing to help us navigate this process to get
the PR merged?

Thanks,
Carin

On Tue, Oct 2, 2018 at 8:42 AM Carin Meier  wrote:

> Marco - Thanks for the "dry run" idea. It will give everyone a clear idea
> of the process and what the expected results will look like.
>
> - I took my fork of the repo and synced my master branch.
> - @iblis17 made a copy of the branch of the Julia import PR and submitted
> it to my repo
> - I merged it with the "Merge" option through the web interface.
>
> Here is a gif of the process of merging:
> http://g.recordit.co/DzBcFtnjmV.gif
> Here is the result of the repo:
> https://github.com/gigasquid/incubator-mxnet
>
> Please everyone take a look and validate that this looks ok.
>
> If there are no objections, Marco - could you please take the lead in
> requesting the actions from INFRA?
>
> It will be great to *finally* get this PR in  :)
>
> Thanks,
> Carin
>
> <https://github.com/gigasquid/incubator-mxnet/commits?author=iblis17>
>
>
>
> On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang  wrote:
>
>> Sorry, here is the image: https://imgur.com/V5wd2XB
>>
>> And here is the github document on the 3 different merge options for the
>> web UI button:
>> https://help.github.com/articles/about-pull-request-merges/
>>
>> On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
>>  wrote:
>>
>> > Could you upload the picture somewhere please? HTML is being stripped
>> out
>> > on email lists.
>> >
>> > Chiyuan Zhang  schrieb am So., 30. Sep. 2018, 03:44:
>> >
>> > > There is an option in the repo settings menu to disable or enable
>> > > merge-commit for PR, see a screenshot below (from a different github
>> > > project):
>> > >
>> > > [image: image.png]
>> > >
>> > > My guess is that this is disabled for the reason to avoid creating
>> > > non-linear history for standard PRs (as oppose to technical problem).
>> But
>> > > this is only my guess, it would be great if someone could confirm.
>> > >
>> > > Best,
>> > > Chiyuan
>> > >
>> > > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier 
>> > wrote:
>> > >
>> > >> I believe so, but if someone wants to confirm it would be great.
>> > >> Unfortunately, I just came down with a cold/flu so I will be out of
>> > >> communication for a bit
>> > >>
>> > >> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
>> > >>  wrote:
>> > >>
>> > >> > Are we sure that this is due to lacking permissions and not
>> because of
>> > >> some
>> > >> > technical limitation? If we are certain, we can ask out mentors to
>> > >> create a
>> > >> > ticket with Apache Infra to make that switch.
>> > >> >
>> > >> > -Marco
>> > >> >
>> > >> > Carin Meier  schrieb am Sa., 29. Sep. 2018,
>> > >> 01:17:
>> > >> >
>> > >> > > I made a test regular merge commit into a copy of master. It
>> seemed
>> > >> to go
>> > >> > > fine. Here is a listing of what it will look like for everyone.
>> > >> > >
>> > >> > >
>> > >> >
>> > >>
>> >
>> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
>> > >> > >
>> > >> > > Although, I would be happy to push the merge button. I think the
>> > most
>> > >> > > important thing is to get the PR merged, so whatever way is the
>> best
>> > >> to
>> > >> > > make that happen, let's do it.
>> > >> > >
>> > >> > > So - Does the regular merge seem like a good option?
>> > >> > > If so, what is the best way to make that happen?
>> > >> > >
>> > >> > >
>> > >> > > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang > >
>> > >> wrote:
>> > >> > >
>> > >> > > > Agreed with Pedro. Maybe the merge-commit option from the
>> github
>> > >> > > interface
>> > >> 

Re: Which merge option to use on the Import Julia binding PR?

2018-10-02 Thread Carin Meier
Marco - Thanks for the "dry run" idea. It will give everyone a clear idea
of the process and what the expected results will look like.

- I took my fork of the repo and synced my master branch.
- @iblis17 made a copy of the branch of the Julia import PR and submitted
it to my repo
- I merged it with the "Merge" option through the web interface.

Here is a gif of the process of merging: http://g.recordit.co/DzBcFtnjmV.gif
Here is the result of the repo: https://github.com/gigasquid/incubator-mxnet

Please everyone take a look and validate that this looks ok.

If there are no objections, Marco - could you please take the lead in
requesting the actions from INFRA?

It will be great to *finally* get this PR in  :)

Thanks,
Carin

<https://github.com/gigasquid/incubator-mxnet/commits?author=iblis17>



On Sat, Sep 29, 2018 at 10:02 PM Chiyuan Zhang  wrote:

> Sorry, here is the image: https://imgur.com/V5wd2XB
>
> And here is the github document on the 3 different merge options for the
> web UI button: https://help.github.com/articles/about-pull-request-merges/
>
> On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
>  wrote:
>
> > Could you upload the picture somewhere please? HTML is being stripped out
> > on email lists.
> >
> > Chiyuan Zhang  schrieb am So., 30. Sep. 2018, 03:44:
> >
> > > There is an option in the repo settings menu to disable or enable
> > > merge-commit for PR, see a screenshot below (from a different github
> > > project):
> > >
> > > [image: image.png]
> > >
> > > My guess is that this is disabled for the reason to avoid creating
> > > non-linear history for standard PRs (as oppose to technical problem).
> But
> > > this is only my guess, it would be great if someone could confirm.
> > >
> > > Best,
> > > Chiyuan
> > >
> > > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier 
> > wrote:
> > >
> > >> I believe so, but if someone wants to confirm it would be great.
> > >> Unfortunately, I just came down with a cold/flu so I will be out of
> > >> communication for a bit
> > >>
> > >> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
> > >>  wrote:
> > >>
> > >> > Are we sure that this is due to lacking permissions and not because
> of
> > >> some
> > >> > technical limitation? If we are certain, we can ask out mentors to
> > >> create a
> > >> > ticket with Apache Infra to make that switch.
> > >> >
> > >> > -Marco
> > >> >
> > >> > Carin Meier  schrieb am Sa., 29. Sep. 2018,
> > >> 01:17:
> > >> >
> > >> > > I made a test regular merge commit into a copy of master. It
> seemed
> > >> to go
> > >> > > fine. Here is a listing of what it will look like for everyone.
> > >> > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
> > >> > >
> > >> > > Although, I would be happy to push the merge button. I think the
> > most
> > >> > > important thing is to get the PR merged, so whatever way is the
> best
> > >> to
> > >> > > make that happen, let's do it.
> > >> > >
> > >> > > So - Does the regular merge seem like a good option?
> > >> > > If so, what is the best way to make that happen?
> > >> > >
> > >> > >
> > >> > > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang 
> > >> wrote:
> > >> > >
> > >> > > > Agreed with Pedro. Maybe the merge-commit option from the github
> > >> > > interface
> > >> > > > was disabled for a reason. But as Pedro said, maybe it is good
> to
> > >> > > > temporarily enable it for this PR and merge using that.
> > >> > > >
> > >> > > >
> > >> > > >- It should be technically easier than rebasing due to the
> > >> > > >git-subtree-import issue we are currently having
> > >> > > >- It also avoid stacking a huge commit history on *top* of
> > >> current
> > >> > > >history
> > >> > > >- The downside is probably the history of the project is not
> > >> linear
> > >> > > >anymore, but I think this is actually what we would like to
>

Re: Which merge option to use on the Import Julia binding PR?

2018-09-29 Thread Carin Meier
I believe so, but if someone wants to confirm it would be great.
Unfortunately, I just came down with a cold/flu so I will be out of
communication for a bit

On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
 wrote:

> Are we sure that this is due to lacking permissions and not because of some
> technical limitation? If we are certain, we can ask out mentors to create a
> ticket with Apache Infra to make that switch.
>
> -Marco
>
> Carin Meier  schrieb am Sa., 29. Sep. 2018, 01:17:
>
> > I made a test regular merge commit into a copy of master. It seemed to go
> > fine. Here is a listing of what it will look like for everyone.
> >
> >
> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
> >
> > Although, I would be happy to push the merge button. I think the most
> > important thing is to get the PR merged, so whatever way is the best to
> > make that happen, let's do it.
> >
> > So - Does the regular merge seem like a good option?
> > If so, what is the best way to make that happen?
> >
> >
> > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang  wrote:
> >
> > > Agreed with Pedro. Maybe the merge-commit option from the github
> > interface
> > > was disabled for a reason. But as Pedro said, maybe it is good to
> > > temporarily enable it for this PR and merge using that.
> > >
> > >
> > >- It should be technically easier than rebasing due to the
> > >git-subtree-import issue we are currently having
> > >- It also avoid stacking a huge commit history on *top* of current
> > >history
> > >- The downside is probably the history of the project is not linear
> > >anymore, but I think this is actually what we would like to have for
> > > this
> > >particular case, because the contents of the main repo and the julia
> > > branch
> > >actually does not overlap. So it makes sense to have two tails with
> > > their
> > >own history.
> > >
> > > Carin: I guess if someone with admin permission on the github could
> > > temporarily enable the merge-commit option, then pushing the button on
> > the
> > > web might simply work.
> > >
> > > Best,
> > > Chiyuan
> > >
> > > On Fri, Sep 28, 2018 at 2:53 PM Carin Meier 
> > wrote:
> > >
> > > > Pedro - Maybe a merge commit is a better answer in this case. I
> > > originally
> > > > ruled it out since it wasn't an option in the github web interface,
> but
> > > > since this looks like it is going to have to be done outside it
> because
> > > of
> > > > the subtrees anyway, it might be a better fit.
> > > >
> > > > On Fri, Sep 28, 2018 at 5:07 PM Carin Meier 
> > > wrote:
> > > >
> > > > > We are actually running into troubles with using the subtree and
> the
> > > > > rebase. Since it looks like this is not going to be a simple,
> "click
> > > the
> > > > > button" through the web page merge, I rather hand this task off to
> > > > someone
> > > > > with more context in making sure it gets in there correctly.
> > > > >
> > > > > Chiyuan or any others, would you be willing to take this over?
> > > > >
> > > > > Thanks,
> > > > > Carin
> > > > >
> > > > > On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy 
> > > wrote:
> > > > >
> > > > >> Should we try to first being into a branch and then try merge that
> > > > >> branch?
> > > > >>
> > > > >> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy <
> > > > pedro.larroy.li...@gmail.com>
> > > > >> wrote:
> > > > >> >
> > > > >> > I'm not familiar with the specifics of this contribution, as a
> > > general
> > > > >> > approach my understanding is that if the list of commits is big
> > and
> > > > you
> > > > >> > want to preserve history, usually merging is better so you keep
> > > > history
> > > > >> and
> > > > >> > causality, if you rebase all the commits on top of master you
> are
> > > > >> changing
> > > > >> > the history of these commits which can't be individually
> reverted
> > as
> > > > >> some
> > > > >> > ha

Re: Which merge option to use on the Import Julia binding PR?

2018-09-28 Thread Carin Meier
I made a test regular merge commit into a copy of master. It seemed to go
fine. Here is a listing of what it will look like for everyone.

https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import

Although, I would be happy to push the merge button. I think the most
important thing is to get the PR merged, so whatever way is the best to
make that happen, let's do it.

So - Does the regular merge seem like a good option?
If so, what is the best way to make that happen?


On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang  wrote:

> Agreed with Pedro. Maybe the merge-commit option from the github interface
> was disabled for a reason. But as Pedro said, maybe it is good to
> temporarily enable it for this PR and merge using that.
>
>
>- It should be technically easier than rebasing due to the
>git-subtree-import issue we are currently having
>- It also avoid stacking a huge commit history on *top* of current
>history
>- The downside is probably the history of the project is not linear
>anymore, but I think this is actually what we would like to have for
> this
>particular case, because the contents of the main repo and the julia
> branch
>actually does not overlap. So it makes sense to have two tails with
> their
>own history.
>
> Carin: I guess if someone with admin permission on the github could
> temporarily enable the merge-commit option, then pushing the button on the
> web might simply work.
>
> Best,
> Chiyuan
>
> On Fri, Sep 28, 2018 at 2:53 PM Carin Meier  wrote:
>
> > Pedro - Maybe a merge commit is a better answer in this case. I
> originally
> > ruled it out since it wasn't an option in the github web interface, but
> > since this looks like it is going to have to be done outside it because
> of
> > the subtrees anyway, it might be a better fit.
> >
> > On Fri, Sep 28, 2018 at 5:07 PM Carin Meier 
> wrote:
> >
> > > We are actually running into troubles with using the subtree and the
> > > rebase. Since it looks like this is not going to be a simple, "click
> the
> > > button" through the web page merge, I rather hand this task off to
> > someone
> > > with more context in making sure it gets in there correctly.
> > >
> > > Chiyuan or any others, would you be willing to take this over?
> > >
> > > Thanks,
> > > Carin
> > >
> > > On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy 
> wrote:
> > >
> > >> Should we try to first being into a branch and then try merge that
> > >> branch?
> > >>
> > >> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy <
> > pedro.larroy.li...@gmail.com>
> > >> wrote:
> > >> >
> > >> > I'm not familiar with the specifics of this contribution, as a
> general
> > >> > approach my understanding is that if the list of commits is big and
> > you
> > >> > want to preserve history, usually merging is better so you keep
> > history
> > >> and
> > >> > causality, if you rebase all the commits on top of master you are
> > >> changing
> > >> > the history of these commits which can't be individually reverted as
> > >> some
> > >> > have suggested before. Maybe is because I come from a mercurial
> > >> background,
> > >> > but my initial impression would be either to:
> > >> > 1. squash everything and rebase
> > >> > 2. or merge without rebasing or squashing.
> > >> >
> > >> > Pedro.
> > >> >
> > >> >> On Thu, Sep 27, 2018 at 3:10 PM Carin Meier 
> > >> wrote:
> > >> >>
> > >> >> Thanks everyone for the input. I'll try to summarize the feedback
> > from
> > >> the
> > >> >> responses:
> > >> >>
> > >> >> Using Squash-Merge is the project standard for very good reasons.
> > >> However,
> > >> >> in the case of this PR to bring in the Julia language from its
> > sibling
> > >> >> repo, we want to preserve all the individual commits of the many
> > >> >> contributors that have worked over multiple years to make this a
> > great
> > >> >> language binding. We will use Rebase-Merge for it.
> > >> >>
> > >> >> Chiyuan - thanks for the suggestion of using a tag. I think we can
> > try
> > >> it
> > >> >> initially without it since there are other ways to browse the
&

Re: Which merge option to use on the Import Julia binding PR?

2018-09-28 Thread Carin Meier
Pedro - Maybe a merge commit is a better answer in this case. I originally
ruled it out since it wasn't an option in the github web interface, but
since this looks like it is going to have to be done outside it because of
the subtrees anyway, it might be a better fit.

On Fri, Sep 28, 2018 at 5:07 PM Carin Meier  wrote:

> We are actually running into troubles with using the subtree and the
> rebase. Since it looks like this is not going to be a simple, "click the
> button" through the web page merge, I rather hand this task off to someone
> with more context in making sure it gets in there correctly.
>
> Chiyuan or any others, would you be willing to take this over?
>
> Thanks,
> Carin
>
> On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy  wrote:
>
>> Should we try to first being into a branch and then try merge that
>> branch?
>>
>> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy 
>> wrote:
>> >
>> > I'm not familiar with the specifics of this contribution, as a general
>> > approach my understanding is that if the list of commits is big and you
>> > want to preserve history, usually merging is better so you keep history
>> and
>> > causality, if you rebase all the commits on top of master you are
>> changing
>> > the history of these commits which can't be individually reverted as
>> some
>> > have suggested before. Maybe is because I come from a mercurial
>> background,
>> > but my initial impression would be either to:
>> > 1. squash everything and rebase
>> > 2. or merge without rebasing or squashing.
>> >
>> > Pedro.
>> >
>> >> On Thu, Sep 27, 2018 at 3:10 PM Carin Meier 
>> wrote:
>> >>
>> >> Thanks everyone for the input. I'll try to summarize the feedback from
>> the
>> >> responses:
>> >>
>> >> Using Squash-Merge is the project standard for very good reasons.
>> However,
>> >> in the case of this PR to bring in the Julia language from its sibling
>> >> repo, we want to preserve all the individual commits of the many
>> >> contributors that have worked over multiple years to make this a great
>> >> language binding. We will use Rebase-Merge for it.
>> >>
>> >> Chiyuan - thanks for the suggestion of using a tag. I think we can try
>> it
>> >> initially without it since there are other ways to browse the commit
>> >> history, like looking at the PRs. But, we can add the tag
>> retroactively if
>> >> people start having trouble.
>> >>
>> >> If there no objections, I will merge the PR using the above method in
>> my
>> >> morning (EST).
>> >>
>> >> Thanks everyone! I'm looking forward to having the Julia community
>> join the
>> >> main repo and increasing our collaboration with them.
>> >>
>> >> Best,
>> >> Carin
>> >>
>> >>> On Thu, Sep 27, 2018 at 1:37 PM Chiyuan Zhang 
>> wrote:
>> >>>
>> >>> +1 for rebase and merge. As a workaround for the aforementioned issue,
>> >>> maybe we can create a tag for the commit before the merge, so that in
>> >> case
>> >>> people want to browse the recent main-repo commits by skipping this
>> big
>> >>> chunk of rebased commits, there is a pointer to take his or her hand
>> on.
>> >>>
>> >>> Best,
>> >>> Chiyuan
>> >>>
>> >>>> On Thu, Sep 27, 2018 at 7:34 AM Jason Dai 
>> wrote:
>> >>>>
>> >>>> +1 to rebase and merge to preserve and track the contributions.
>> >>>>
>> >>>> Thanks,
>> >>>> -Jason
>> >>>>
>> >>>> On Thu, Sep 27, 2018 at 12:27 PM Aaron Markham <
>> >>> aaron.s.mark...@gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>>> +1 to rebase and merge to retain the efforts of all of the
>> >>> contributors.
>> >>>> If
>> >>>>> there's some git maintenance that can trim it down from 700+ commits
>> >>> then
>> >>>>> maybe that's a compromise.
>> >>>>>
>> >>>>>> On Wed, Sep 26, 2018, 21:23 Naveen Swamy 
>> wrote:
>> >>>>>>
>> >>>>>> this PR comes from more than 1 individual, if we squash merge we'll
>> >>> not
>> &g

Re: Which merge option to use on the Import Julia binding PR?

2018-09-28 Thread Carin Meier
We are actually running into troubles with using the subtree and the
rebase. Since it looks like this is not going to be a simple, "click the
button" through the web page merge, I rather hand this task off to someone
with more context in making sure it gets in there correctly.

Chiyuan or any others, would you be willing to take this over?

Thanks,
Carin

On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy  wrote:

> Should we try to first being into a branch and then try merge that branch?
>
> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy 
> wrote:
> >
> > I'm not familiar with the specifics of this contribution, as a general
> > approach my understanding is that if the list of commits is big and you
> > want to preserve history, usually merging is better so you keep history
> and
> > causality, if you rebase all the commits on top of master you are
> changing
> > the history of these commits which can't be individually reverted as some
> > have suggested before. Maybe is because I come from a mercurial
> background,
> > but my initial impression would be either to:
> > 1. squash everything and rebase
> > 2. or merge without rebasing or squashing.
> >
> > Pedro.
> >
> >> On Thu, Sep 27, 2018 at 3:10 PM Carin Meier 
> wrote:
> >>
> >> Thanks everyone for the input. I'll try to summarize the feedback from
> the
> >> responses:
> >>
> >> Using Squash-Merge is the project standard for very good reasons.
> However,
> >> in the case of this PR to bring in the Julia language from its sibling
> >> repo, we want to preserve all the individual commits of the many
> >> contributors that have worked over multiple years to make this a great
> >> language binding. We will use Rebase-Merge for it.
> >>
> >> Chiyuan - thanks for the suggestion of using a tag. I think we can try
> it
> >> initially without it since there are other ways to browse the commit
> >> history, like looking at the PRs. But, we can add the tag retroactively
> if
> >> people start having trouble.
> >>
> >> If there no objections, I will merge the PR using the above method in my
> >> morning (EST).
> >>
> >> Thanks everyone! I'm looking forward to having the Julia community join
> the
> >> main repo and increasing our collaboration with them.
> >>
> >> Best,
> >> Carin
> >>
> >>> On Thu, Sep 27, 2018 at 1:37 PM Chiyuan Zhang 
> wrote:
> >>>
> >>> +1 for rebase and merge. As a workaround for the aforementioned issue,
> >>> maybe we can create a tag for the commit before the merge, so that in
> >> case
> >>> people want to browse the recent main-repo commits by skipping this big
> >>> chunk of rebased commits, there is a pointer to take his or her hand
> on.
> >>>
> >>> Best,
> >>> Chiyuan
> >>>
> >>>> On Thu, Sep 27, 2018 at 7:34 AM Jason Dai 
> wrote:
> >>>>
> >>>> +1 to rebase and merge to preserve and track the contributions.
> >>>>
> >>>> Thanks,
> >>>> -Jason
> >>>>
> >>>> On Thu, Sep 27, 2018 at 12:27 PM Aaron Markham <
> >>> aaron.s.mark...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> +1 to rebase and merge to retain the efforts of all of the
> >>> contributors.
> >>>> If
> >>>>> there's some git maintenance that can trim it down from 700+ commits
> >>> then
> >>>>> maybe that's a compromise.
> >>>>>
> >>>>>> On Wed, Sep 26, 2018, 21:23 Naveen Swamy 
> wrote:
> >>>>>>
> >>>>>> this PR comes from more than 1 individual, if we squash merge we'll
> >>> not
> >>>>> be
> >>>>>> able to attribute the contribution of those individuals.
> >>>>>>
> >>>>>> +1 to rebase merge to preserve history
> >>>>>>
> >>>>>> On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen <
> >>>> tqc...@cs.washington.edu>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> One of the main reason for a rebase merge is that it preserves
> >> the
> >>>>> commit
> >>>>>>> history of the MXNet.jl package contributors, and given that the
> >>>>> project
> >>>>>>> has been

Re: Feedback request for new Java API

2018-09-28 Thread Carin Meier
Sorry bad paste on the gist - here is the good one
https://gist.github.com/gigasquid/01cd48f563db4739910592dd9ac9db20

On Fri, Sep 28, 2018 at 10:24 AM Carin Meier  wrote:

> +1 on option #2
>
> In the case of minimizing the the overhead for code maintenance, I wanted
> to suggest the option of investigating generating code from the Java
> Reflection for the Java APIs.  I did a quick gist from Clojure of what the
> generated classes look like from the current Scala Symbol.api for
> FullyConnected here
> https://gist.github.com/gigasquid/01cd48f563db4739910592
>
> I looks like that there is always a base Java class generated will all the
> arguments. If this is the case, then there is a possibility to generate a
> Java api based on this Java method automatically with just a conversion for
> the Scala option and it might be reusable for all the packages.
>
> Not sure if it will work for this use case, but thought I would bring it
> up in case it's helpful.
>
> - Carin
>
> On Fri, Sep 28, 2018 at 7:05 AM Davydenko, Denis 
> wrote:
>
>> +1 on option #2. Having clear Java interface for NDArray, from my
>> perspective, would be a better experience for Java users as it won't
>> require them to deal with Scala code in any capacity. Overhead of extra
>> code for additional macros is justified, in my mind, as it will be
>> introduced with option #1 either way, just in a different place.
>>
>> --
>> Thanks,
>> Denis
>>
>> On 9/27/18, 6:14 PM, "YiZhi Liu"  wrote:
>>
>> I vote for "2.) Leave the existing macro in place and add another
>> which generates a Java friendly version"
>>
>> @Qing @Andrew, could you give some examples, so that people can better
>> understand how it provides "best possible experience" to Java users.
>>
>> I have no strong preference between having JavaShape & JavaContext or
>> not.
>> On Thu, Sep 27, 2018 at 5:56 PM Andrew Ayres <
>> andrew.f.ay...@gmail.com> wrote:
>> >
>> > That's not really the conversation I'm wanting to have. I want a
>> discussion
>> > about the macros with respect to NDArray so that we can get
>> agreement on
>> > our path forward with respect to implementing the NDArray wrapper.
>> >
>> > The design that was put forth and agreed to was for a a Java
>> wrapper around
>> > the Scala API. Adding a bunch of Java friendly methods inside the
>> Scala
>> > code would create a mess for users. Maintenance would be
>> essentially the
>> > same for both because either way you're going to be updating Java
>> methods
>> > when you make Scala changes.
>> >
>> > Let's please stick with the issue in the original email.
>> >
>> > Thanks,
>> > Andrew
>> >
>> > On Thu, Sep 27, 2018 at 5:22 PM Qing Lan 
>> wrote:
>> >
>> > > I would like to loop this back a layer. Current, there is a
>> discussion in
>> > > the MXNet Scala community on the ways to implement the Java APIs.
>> Currently
>> > > there are two thoughts:
>> > >
>> > > 1. Make Scala Java Friendly (Create Java compatible methods in
>> the Scala
>> > > Class. such as NDArray with Java compatible constructor)
>> > > 2. Make Java friendly wrappers in Scala (Andrew's explanation
>> below)
>> > >
>> > > The first approach require minimum input from our side to
>> implement
>> > > however bring user a bunch of useless api they may not want to
>> use. It also
>> > > makes Scala package heavier. The good thing is these two packages
>> require
>> > > minimum maintenance cost. As a tradeoff, if any time in the
>> future we want
>> > > to make Java big (make Java as the primary language supported by
>> MXNet),
>> > > then the migration from Scala to Java will be harmful. Spark
>> consider this
>> > > carefully and decide not to change much on their Scala code base
>> to make it
>> > > more Java.
>> > >
>> > > The second approach will make unique NDArray, Shape, Context and
>> more. The
>> > > good thing about this is we can always holds a version control on
>> Java.
>> > > Some breaking changes on Scala may not influence much on Java. It
>> did the
>> > > best way to decouple the module and good f

Re: Feedback request for new Java API

2018-09-28 Thread Carin Meier
+1 on option #2

In the case of minimizing the the overhead for code maintenance, I wanted
to suggest the option of investigating generating code from the Java
Reflection for the Java APIs.  I did a quick gist from Clojure of what the
generated classes look like from the current Scala Symbol.api for
FullyConnected here https://gist.github.com/gigasquid/01cd48f563db4739910592

I looks like that there is always a base Java class generated will all the
arguments. If this is the case, then there is a possibility to generate a
Java api based on this Java method automatically with just a conversion for
the Scala option and it might be reusable for all the packages.

Not sure if it will work for this use case, but thought I would bring it up
in case it's helpful.

- Carin

On Fri, Sep 28, 2018 at 7:05 AM Davydenko, Denis 
wrote:

> +1 on option #2. Having clear Java interface for NDArray, from my
> perspective, would be a better experience for Java users as it won't
> require them to deal with Scala code in any capacity. Overhead of extra
> code for additional macros is justified, in my mind, as it will be
> introduced with option #1 either way, just in a different place.
>
> --
> Thanks,
> Denis
>
> On 9/27/18, 6:14 PM, "YiZhi Liu"  wrote:
>
> I vote for "2.) Leave the existing macro in place and add another
> which generates a Java friendly version"
>
> @Qing @Andrew, could you give some examples, so that people can better
> understand how it provides "best possible experience" to Java users.
>
> I have no strong preference between having JavaShape & JavaContext or
> not.
> On Thu, Sep 27, 2018 at 5:56 PM Andrew Ayres 
> wrote:
> >
> > That's not really the conversation I'm wanting to have. I want a
> discussion
> > about the macros with respect to NDArray so that we can get
> agreement on
> > our path forward with respect to implementing the NDArray wrapper.
> >
> > The design that was put forth and agreed to was for a a Java wrapper
> around
> > the Scala API. Adding a bunch of Java friendly methods inside the
> Scala
> > code would create a mess for users. Maintenance would be essentially
> the
> > same for both because either way you're going to be updating Java
> methods
> > when you make Scala changes.
> >
> > Let's please stick with the issue in the original email.
> >
> > Thanks,
> > Andrew
> >
> > On Thu, Sep 27, 2018 at 5:22 PM Qing Lan 
> wrote:
> >
> > > I would like to loop this back a layer. Current, there is a
> discussion in
> > > the MXNet Scala community on the ways to implement the Java APIs.
> Currently
> > > there are two thoughts:
> > >
> > > 1. Make Scala Java Friendly (Create Java compatible methods in the
> Scala
> > > Class. such as NDArray with Java compatible constructor)
> > > 2. Make Java friendly wrappers in Scala (Andrew's explanation
> below)
> > >
> > > The first approach require minimum input from our side to implement
> > > however bring user a bunch of useless api they may not want to
> use. It also
> > > makes Scala package heavier. The good thing is these two packages
> require
> > > minimum maintenance cost. As a tradeoff, if any time in the future
> we want
> > > to make Java big (make Java as the primary language supported by
> MXNet),
> > > then the migration from Scala to Java will be harmful. Spark
> consider this
> > > carefully and decide not to change much on their Scala code base
> to make it
> > > more Java.
> > >
> > > The second approach will make unique NDArray, Shape, Context and
> more. The
> > > good thing about this is we can always holds a version control on
> Java.
> > > Some breaking changes on Scala may not influence much on Java. It
> did the
> > > best way to decouple the module and good for us to build unique
> pipeline
> > > for Java. The bad thing with this design is the maintenance cost
> as we need
> > > to keep two code bases, but it also make Java side easy to change
> to make
> > > it better compatible with users.
> > >
> > > Thanks,
> > > Qing
> > >
> > > On 9/27/18, 3:25 PM, "Andrew Ayres" 
> wrote:
> > >
> > > Hi,
> > >
> > > Currently, we're working to implement a new Java API and would
> like
> > > some
> > > feedback from the community on an implementation detail. In
> short, the
> > > new
> > > Java API will use the existing Scala API (in a manner similar
> to how
> > > the
> > > current Clojure API works). This basically means that we're
> making Java
> > > friendly wrappers to call the existing Scala API.
> > >
> > > The feedback we're looking for is on the implementation of
> NDArray.
> > > Scala's
> > > NDArray has a significant amount of code which is generated
> via macros
> > > and
> > > we've got two viable paths 

Re: Which merge option to use on the Import Julia binding PR?

2018-09-27 Thread Carin Meier
Thanks everyone for the input. I'll try to summarize the feedback from the
responses:

Using Squash-Merge is the project standard for very good reasons. However,
in the case of this PR to bring in the Julia language from its sibling
repo, we want to preserve all the individual commits of the many
contributors that have worked over multiple years to make this a great
language binding. We will use Rebase-Merge for it.

Chiyuan - thanks for the suggestion of using a tag. I think we can try it
initially without it since there are other ways to browse the commit
history, like looking at the PRs. But, we can add the tag retroactively if
people start having trouble.

If there no objections, I will merge the PR using the above method in my
morning (EST).

Thanks everyone! I'm looking forward to having the Julia community join the
main repo and increasing our collaboration with them.

Best,
Carin

On Thu, Sep 27, 2018 at 1:37 PM Chiyuan Zhang  wrote:

> +1 for rebase and merge. As a workaround for the aforementioned issue,
> maybe we can create a tag for the commit before the merge, so that in case
> people want to browse the recent main-repo commits by skipping this big
> chunk of rebased commits, there is a pointer to take his or her hand on.
>
> Best,
> Chiyuan
>
> On Thu, Sep 27, 2018 at 7:34 AM Jason Dai  wrote:
>
> > +1 to rebase and merge to preserve and track the contributions.
> >
> > Thanks,
> > -Jason
> >
> > On Thu, Sep 27, 2018 at 12:27 PM Aaron Markham <
> aaron.s.mark...@gmail.com>
> > wrote:
> >
> > > +1 to rebase and merge to retain the efforts of all of the
> contributors.
> > If
> > > there's some git maintenance that can trim it down from 700+ commits
> then
> > > maybe that's a compromise.
> > >
> > > On Wed, Sep 26, 2018, 21:23 Naveen Swamy  wrote:
> > >
> > > > this PR comes from more than 1 individual, if we squash merge we'll
> not
> > > be
> > > > able to attribute the contribution of those individuals.
> > > >
> > > > +1 to rebase merge to preserve history
> > > >
> > > > On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen <
> > tqc...@cs.washington.edu>
> > > > wrote:
> > > >
> > > > > One of the main reason for a rebase merge is that it preserves the
> > > commit
> > > > > history of the MXNet.jl package contributors, and given that the
> > > project
> > > > > has been evolved since 2015 and has always been a high-quality
> > language
> > > > > module for MXNet.
> > > > >
> > > > > I think we should take an exception here to preserve the commit
> > history
> > > > of
> > > > > each individual contributors to the Julia binding and welcome them
> to
> > > the
> > > > > community.
> > > > >
> > > > > Tianqi
> > > > >
> > > > > On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen <
> > tqc...@cs.washington.edu>
> > > > > wrote:
> > > > >
> > > > > > In this particular case, I would suggest rebase and merge.
> > > > > >
> > > > > > The main reasoning is that the commit log of the Julia binding is
> > not
> > > > > > simple WIP commits, every commit there has been done through
> > > testcases
> > > > > and
> > > > > > it is important for us to respect the developer of the effort. It
> > is
> > > > also
> > > > > > good to trace back the history of the commits more easily.
> > > > > >
> > > > > > Tianqi
> > > > > >
> > > > > >
> > > > > > Tianqi
> > > > > >
> > > > > > On Wed, Sep 26, 2018 at 5:34 PM Carin Meier <
> carinme...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > >> Chiyuan,
> > > > > >>
> > > > > >> Thanks for the prompt to find some clarity of the pros and cons
> of
> > > > > each. I
> > > > > >> think that will help drive us to the right decision. I think
> some
> > of
> > > > > those
> > > > > >> reasons are the ones you listed. I will take a stab below at
> > > outlining
> > > > > >> what
> > > > > >> I see. Feel free to chime in if I missed any.
> > > > > >>
> > > > > >> *Squash and Me

Re: Which merge option to use on the Import Julia binding PR?

2018-09-26 Thread Carin Meier
Chiyuan,

Thanks for the prompt to find some clarity of the pros and cons of each. I
think that will help drive us to the right decision. I think some of those
reasons are the ones you listed. I will take a stab below at outlining what
I see. Feel free to chime in if I missed any.

*Squash and Merge*
  *Pros* - It is the project standard
  - It will provide one commit for the feature and lessen the need
for 700+ commits rebased on top of master.
 - It is easier for a user to do git log to browse commits and see
what was features were added.
  *Cons* - I don't know how github would handle squashing all those commit
messages into one. Will it be too much?
- You lose the granularity of the features individual commits

*Rebase and Merge*
 * Pros *- You don't have a huge commit message with one commit
  -  You do have the granularity of the individual features of the
commit
 * Cons *- It is not the project standard
   - You have 700+ commits on top of master that might be harder to
see the ones that went in right before. (like someone browsing commits)

On Wed, Sep 26, 2018 at 8:12 PM Chiyuan Zhang  wrote:

> Hi Carin,
>
> Can you clarify the pros and cons of the two approaches? Is the main
> concern here about logistics (e.g. preserving the history of the original
> repo and developments) or technical issue (e.g. using squash might end up
> with a hge commit message that might be difficult or hard to handle)?
>
> I think it might not be very likely that someone is going to cherry pick
> revert some of the commits. But preserving the commit history is still
> useful in case one need to trace the change or bisect for some regression
> bugs, etc.
>
> Just to provide some context: the PR actually contains 700+ commits, and it
> dates back to 2015. The development of the Julia binding started in the
> early stage of MXNet. We started with a separate repo due to the
> requirement of the package system of julia.
>
> Best,
> Chiyuan
>
> On Wed, Sep 26, 2018 at 3:41 PM Carin Meier  wrote:
>
> > The Import Julia binding PR ,(
> > https://github.com/apache/incubator-mxnet/pull/10149), is getting very
> > close to being merged. Because of the large number of commits there was a
> > suggestion not to use the usual "Squash and Merge".  The only option
> would
> > be "Rebase and Merge" since merging with a merge commit is not enabled
> for
> > the project.
> >
> > *Squash and Merge* - The commits from this branch will be combined into
> one
> > commit in the base branch (With all the commit messages combined)
> >
> > *Rebase and Merge* - The commits from this branch will be rebased and
> added
> > to the base branch
> >
> > The PR is over 250+ commits (Github won't show all of them)
> >
> > Thoughts about how we should handle the merge?
> >
> > Thanks,
> > Carin
> >
>


Re: Which merge option to use on the Import Julia binding PR?

2018-09-26 Thread Carin Meier
Kellen,

Thanks for your input. We can certainly try squash and merge and see if
there are any issues.

My inclination is same as yours in the case of the git rework, but I'm not
sure how feasible it is since commits go back to Jan 2017 - It's bringing
in this repo work I believe https://github.com/dmlc/MXNet.jl.

Here is an example of the first commit in the PR
Commits on Jan 29, 2017

   1.

   Merge pull request
   
<https://github.com/apache/incubator-mxnet/pull/10149/commits/79d80b6e3f2e66cf42a5e59d0f383ade8e1b4e95>
#196 <https://github.com/apache/incubator-mxnet/pull/196> from
   dmlc/vc/fix_win
   
<https://github.com/apache/incubator-mxnet/pull/10149/commits/79d80b6e3f2e66cf42a5e59d0f383ade8e1b4e95>
…
   [image: @vchuravy] <https://github.com/vchuravy>
   vchuravy
   <https://github.com/apache/incubator-mxnet/commits?author=vchuravy>
committed on Jan 29, 2017

   remove usr/setupenv.cmd because it is too invasive



On Wed, Sep 26, 2018 at 7:15 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> My gut feel would be just to squash and merge, it usually works quite well.
>
> Is there any chance that someone might want to cherry-pick, revert or
> rebase any portions of the PR?
>
> If so what I try and is to provide atomic commits the bring small
> individual pieces of value to the codebase.  This often means at the end of
> the PR I'd do some git hygiene, get rework my commits and then force push.
> I try to ensure that I also leave a backup branch in GitHub that contains
> my original git history.  If you have an atomic chain of commits then it
> might make more sense to rebase and merge.
>
> On Wed, Sep 26, 2018, 3:41 PM Carin Meier  wrote:
>
> > The Import Julia binding PR ,(
> > https://github.com/apache/incubator-mxnet/pull/10149), is getting very
> > close to being merged. Because of the large number of commits there was a
> > suggestion not to use the usual "Squash and Merge".  The only option
> would
> > be "Rebase and Merge" since merging with a merge commit is not enabled
> for
> > the project.
> >
> > *Squash and Merge* - The commits from this branch will be combined into
> one
> > commit in the base branch (With all the commit messages combined)
> >
> > *Rebase and Merge* - The commits from this branch will be rebased and
> added
> > to the base branch
> >
> > The PR is over 250+ commits (Github won't show all of them)
> >
> > Thoughts about how we should handle the merge?
> >
> > Thanks,
> > Carin
> >
>


  1   2   >