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

[Jim Jagielski]

+1 (binding)

> On Dec 20, 2018, at 12:24 PM, Steffen Rochel  wrote:
> 
> Dear MXNet community,
> 
> This is the vote to release Apache MXNet (incubating) version v1.4.0.
> Voting will start December 20 noon PST  and close on December 27 noon 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.rc0
> 
> 
> Link to source and signatures on apache dist server:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.0.rc0
> 
> 
> 
> Please remember to TEST first before voting accordingly:
> +1 = approve
> +0 = no opinion
> -1 = disapprove (provide reason)
> 
> 
> Best regards,
> Steffen

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

[Jim Jagielski]

+1 from me (macOS)

> On Nov 16, 2018, at 2:52 AM, kellen sunderland  
> wrote:
> 
> Thanks for organizing the release Anton and for testing Carin and Steffen.
> Lots of great fixes in this release.  As we don't have the required 3
> committers I'd suggest extending the vote for a few days.
> 
> I tested the following on MacOS 10.13, High Sierra:
> 
> INCUBATING IN RELEASE FILE: check.
> LICENSE check.
> NOTICE check.
> SIGNATURE check.
> HASH check.
> DISCLAIMER check.
> SOURCE COMPILES VIA MAKEFILE check.
> SOURCE COMPILES VIA CMAKE check.
> C++ TESTS PASS fail
> Two tests failing for me.
> Build with flags: cmake -DUSE_CUDA=0 -DUSE_CUDNN=0 -DUSE_OPENMP=0
> -DUSE_OPENCV=0 ..
> Ran c++ tests with exclusions: ./tests/mxnet_unit_tests
> --gtest_filter=-GpuTopology.*
> Result:
> [  FAILED  ] 2 tests, listed below:
> [  FAILED  ] ACTIVATION_PERF.ExecuteBidirectional
> [  FAILED  ] ACTIVATION_PERF.TimingCPU
> 
> PYHTON UNIT TESTS PASS check.
> 
> Not sure if the test failures are a regression so I'm +0 (non-binding)
> 
> On Thu, Nov 15, 2018 at 5:43 PM Steffen Rochel 
> wrote:
> 
>> +1 build on MacOS Sierra following instructions on
>> 
>> https://cwiki.apache.org/confluence/display/MXNET/MXNet+Developer+Setup+on+Mac
>> and run one training test.
>> 
>> On Tue, Nov 13, 2018 at 2:34 PM Carin Meier  wrote:
>> 
>>> +1 - Clojure package tested fine with Scala jars
>>> 
>>> On Mon, Nov 12, 2018 at 6:53 PM Anton Chernov 
>> wrote:
>>> 
 Dear MXNet community,
 
 This is the vote to release Apache MXNet (incubating) version 1.3.1.
>>> Voting
 will start now, on Monday the 12th of November 2018 and close on 14:00
 Thursday the 15th of November 2018, Pacific Time (PT).
 
 Link to release notes:
 https://cwiki.apache.org/confluence/x/eZGzBQ
 
 Link to release candidate 1.3.1.rc0:
 https://github.com/apache/incubator-mxnet/releases/tag/1.3.1.rc0
 
 Link to source and signatures on apache dist server:
 https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.3.1.rc0/
 
 Link to scala packages on the staging repo:
 
 * CPU
 
 
>>> 
>> https://repository.apache.org/content/repositories/snapshots/org/apache/mxnet/mxnet-full_2.11-osx-x86_64-cpu/1.3.1-SNAPSHOT/
 
 * GPU
 
 
>>> 
>> https://repository.apache.org/content/repositories/snapshots/org/apache/mxnet/mxnet-full_2.11-linux-x86_64-gpu/1.3.1-SNAPSHOT/
 
 Please remember to TEST first before voting accordingly:
 +1 = approve
 +0 = no opinion
 -1 = disapprove (provide reason)
 
 
 Best regards,
 Anton
 
>>> 
>> 

Re: CLion dev setup tutorial

[Jim Jagielski]

Nice work! Thx for this.

> On Nov 7, 2018, at 9:18 AM, Jose Luis Contreras Santos 
>  wrote:
> 
> Hi all,
> 
> I recently published a guide on how to setup CLion for MXNet development on
> Mac. It's published on Confluence here
> ,
> so if you are interested have a look at it and let me know if there's
> anything which could be improved.
> 
> For non Mac users, there's also a section in the end about remote host
> development. With this  new feature of the upcoming version of CLion, you
> can work on a remote Linux machine using your local IDE.
> 
> Thanks,
> 
> Jose

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

[Jim Jagielski]

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 
>>> 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: [Discussion] Separating PMC and Committership

[Jim Jagielski]

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 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 

Re: Subscription

[Jim Jagielski]

I'd like an invite as well, please :)

> On Sep 29, 2018, at 12:03 PM, Naveen Swamy  wrote:
> 
> Invite sent. Welcome to Apache MXNet Cosmin :).
> 
> 
> On Sat, Sep 29, 2018 at 11:38 AM Cosmin Cătălin Sanda <
> cosmincata...@gmail.com> wrote:
> 
>> Hi, I would like to subscribe to the ASF mxnet channel.
>> 
>> *Cosmin Catalin SANDA*
>> Data Scientist & Engineer
>> Phone: +45.27.30.60.35
>> Web: https://cosminsanda.com
>> 

Maturity Model and Graduation

[Jim Jagielski]

As a newly "minted" mentor, I'm getting my feet wet on determining where the 
project is and where it needs to go in order to be ready for graduation...

Has the project run the Maturity Model against itself? How do we stack up? What 
areas of improvement could we benefit from (this might be independent of what 
the MatModel sez, btw. If you have ideas on where we could be working and 
collaborating better, please bring them up!)?

Cheers!

Re: Propose to discontinue supporting Apache MXNet on Windows 7

[Jim Jagielski]

IMO, either major or minor is fine, not just patch ;)

> On Aug 30, 2018, at 2:34 AM, Lv, Tao A  wrote:
> 
> If we really want to discontinue the support on Win7, maybe it should happen 
> in a major release like 2.0.0.
> 
> 
> -Original Message-
> From: dev-return-4003-tao.a.lv=intel@mxnet.incubator.apache.org 
> [mailto:dev-return-4003-tao.a.lv=intel@mxnet.incubator.apache.org] 
> Sent: Thursday, August 30, 2018 2:21 PM
> To: dev@mxnet.incubator.apache.org
> Subject: Re: Propose to discontinue supporting Apache MXNet on Windows 7
> 
> Hi Hagay,
> 
> To minimize the impact to existing customers, I suggest we support MXNe 1.3 
> installation on Windows but defer all the bug fix to Windows 10 version and 
> ask users to migrate. Then we officially discontinue the support on Windows
> 7 in the 1.4 release.
> 
> Thanks,
> 
> Lin
> 
> On Wed, Aug 29, 2018 at 1:29 PM Hagay Lupesko  wrote:
> 
>> +1 (non-binding)
>> Thanks for raising this Lin!
>> Are you suggesting to do it as part of MXNet 1.3?
>> 
>> On Wed, Aug 29, 2018 at 9:14 AM Srivastava, Rohit Kumar < 
>> srivastava@buckeyemail.osu.edu> wrote:
>> 
>>> +1
>>> 
>>> On 8/29/18, 8:39 AM, "sandeep krishnamurthy" <
>> sandeep.krishn...@gmail.com>
>>> wrote:
>>> 
>>>+1 Thanks for bringing this up.
>>> 
>>>On Wed, Aug 29, 2018 at 6:38 AM Marco de Abreu
>>> wrote:
>>> 
 +1
 
 On Wed, Aug 29, 2018 at 1:08 PM kellen sunderland <
 kellen.sunderl...@gmail.com> wrote:
 
> +1 (non-binding)
> 
> On Wed, Aug 29, 2018, 1:18 AM Anirudh Acharya < 
>>> anirudhk...@gmail.com>
> wrote:
> 
>> +1 for discontinuing.
>> 
>> On Tue, Aug 28, 2018 at 4:11 PM Naveen Swamy <
>> mnnav...@gmail.com
 
 wrote:
>> 
>>> +1 to stop supporting Win7
>>> 
>>> On Tue, Aug 28, 2018 at 3:54 PM Lin Yuan <
>> apefor...@gmail.com>
 wrote:
>>> 
 Dear Community,
 
 
 
 Currently, our MXNet installation guide for Windows 
>>> does
>> not
>>> work
 for
 Windows 7. e.g. Microsoft Visual Studio 2015 is not 
>>> supported on
>> Windows
>>> 7
 <
 
>>> 
>> 
> 
 
>>> 
>> https://visualstudio.microsoft.com/vs/support/vs2015/received-error-sp
>> ecified-program-requires-newer-version-windows/
> .
 In addition, MSFT ended “Mainstream” support for 
>>> Windows 7 in 2015
 (
 
>>> 
>> 
> 
 
>>> 
>> https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-
>> sheet
 ).
 Therefore, it is not possible for developers to build 
>>> MXNet and
> verify
>>> the
 fix on Windows 7 platform. Given that there have been
>> several
 issues
>>> about
 MXNet error on Windows 7 (issue#9271
 
>>> ,
>>> issue
 #8921
 
>>> ,
>>> issue
> #11163
 
>>> ),
>>> it will
>> even
 add
 more burden on developers in the future if we were to 
>>> continue
>> supporting
 Windows 7.
 
 
 
 I therefore would like to propose that we discontinue 
>>> the support
 of
>>> MXNet
 on Windows 7 in the next release.
 
 
 Specifically, this means the following required actions:
 
 1) state the discontinuation of Windows 7 support in 
>>> the release
 note
 
 2) update the MXNet webpage if Windows version is
>> mentioned.
 
 3) update the open Github issues related to Windows 7
 
 
 Please share your thoughts about this proposal and/or 
>>> suggest if
> there
>> is
 any other missing action item from the above.
 
 
 Best Regards,
 
 
 Lin
 
>>> 
>> 
> 
 
>>> 
>>> 
>>>--
>>>Sandeep Krishnamurthy
>>> 
>>> 
>>> 
>> 

Re: Deprecate python 2

[Jim Jagielski]

Would we expect people to be using MXnet in a "enterprise RHEL7" environment?

In other words, RHEL7 is for the enterprise, production environments where
nothing changes and things are, and remain, as stable as stable can be.
Is that really the type of environ where we expect people to be using MXnet?

> On Jul 13, 2018, at 4:29 AM, Marco de Abreu 
>  wrote:
> 
> I can't remember exactly where I found it, but I found the following
> statements:
> - "only a commercially supported subset of Fedora derived packages are
> included in the RHEL distribution" [1]
> - "there are no commercial support contracts or service level agreements
> provided by Red Hat for packages in EPEL" [2]
> - "How can we be sure that someone will maintain the packages until end of
> life of the distribution the packages were built for?" -> "The only way to
> be sure is to do it yourself" [3]
> - "Red Hat Global Support Services will be unable to support or debug
> problems with packages not shipped in standard RHEL channels." [4]
> - "The EPEL repository is not a part of Red Hat Enterprise Linux and does
> not fall under Red Hat's Production Support Scope of Coverage. The
> repository is considered an optional repository and is not tested by Red
> Hat quality engineers." [4]
> 
> Like I said, I've never used RHEL and thus have limited knowledge about the
> conventions. The statements above just gave me the impression that EPEL is
> not a preferred choice for customers in a production. Considering Python2
> is part of the RHEL repository and Python3 only exists in EPEL, I thought
> that this would make sense.
> 
> The stable repository of EPEL is described at [5] and the testing one at
> [6].
> 
> Best regards,
> Marco
> 
> [1]:
> https://fedoraproject.org/wiki/EPEL/FAQ#Why_is_the_Fedora_Project_sponsoring_EPEL.3F
> [2]:
> https://fedoraproject.org/wiki/EPEL/FAQ#Is_EPEL_commercially_supported_by_Red_Hat.3F
> [3]:
> https://fedoraproject.org/wiki/EPEL/FAQ#How_can_we_be_sure_that_someone_will_maintain_the_packages_until_end_of_life_of_the_distribution_the_packages_were_built_for.3F
> [4]: https://access.redhat.com/solutions/3358
> [5]:
> https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F
> [6]: https://fedoraproject.org/wiki/EPEL/testing
> 
> On Fri, Jul 13, 2018 at 8:40 AM Chen HY  wrote:
> 
>> Could you please finding the original document you have read about EPEL?
>> I just check the EPEL website again, failed to find a stable repository
>> you mentioned.
>> As my understanding, EPEL repo is as reliable as other non-commercial rpm
>> repository.
>> 
>> Website: https://fedoraproject.org/wiki/EPEL
>> 
>> HY
>> 
>> 
>> 发件人: Marco de Abreu
>> 发送时间: 2018年7月13日 0:27
>> 收件人: dev@mxnet.incubator.apache.org
>> 主题: Re: Deprecate python 2
>> 
>> Sorry, I pressed the send button too early. I think epel repository is not
>> deemed stable enough that it qualifies to be used in all Enterprise
>> environments - epel itself has a stable and a release repository. I'm not
>> very familiar with CentOS or RHEL, but that's what I read when I designed
>> the CentOS docker containers. If anybody has more knowledge I'm happy to
>> get corrected here :)
>> 
>> -Marco
>> 
>> Marco de Abreu  schrieb am Fr., 13. Juli
>> 2018, 01:23:
>> 
>>> As far as I know is the epel repository not considered stable.
>>> 
>>> Chen HY  schrieb am Fr., 13. Juli 2018, 00:18:
>>> 
 CentOS 7 has Python 3.4.8 and python 3.6.3 in epel repo.
 Is that stable ?
 HY
 发件人: Marco de Abreu
 发送时间: 2018年7月12日 23:00
 收件人: dev@mxnet.incubator.apache.org
 主题: Re: Deprecate python 2
 
 CentOS 7, for example, does not offer stable Python 3 support. We're
>> using
 an unstable version in our CI to verify it none the less. I think
>> that's a
 hard stop for quite a few users.
 
 -Marco
 
 Pedro Larroy  schrieb am Do., 12. Juli
 2018,
 23:51:
 
> Hi
> 
> I would like to know your opinion in regards to deprecating and
>> removing
> Python 2. Maybe for MXNet 2.0 ?
> 
> What's the reason to have support for Python2?
> 
> Pedro.
> 
 
 
>> 
>> 

Re: users@mxnet

[Jim Jagielski]

Just so we are clear: building and fostering a community takes effort. Either 
it is something important to the project, or it's not.

My assumption is that It Is.

> On Jun 18, 2018, at 8:59 PM, YiZhi Liu  wrote:
> 
> I am personally not a big fan of mailing list but agree with Thomas
> that we may get extra users, which worth a try.
> On the other hand, I also have concern that we do not have a community
> big enough to support multiple forums. If people asked questions but
> got no response, that can be worse than not having the mailing list at
> all.
> On Mon, Jun 18, 2018 at 5:46 PM Thomas DELTEIL
>  wrote:
>> 
>> I was actually the one stating that we didn't need a user mailing list
>> during the Seattle meetup, given all the reasons already exposed above.
>> 
>> However given what proponents of a mailing list said, I personally wouldn't
>> mind adding a new channel as a user mailing list, and monitoring it. There
>> seems to be a subset of users, used to apache projects, that wouldn't use
>> the forum but would use a mailing list. Though I think it is not as
>> feature-rich as the forum and there is a risk of dilution of information.
>> It is more about reaching those extra users. If we see a dilution of
>> traffic on the forum towards the mailing list (~currently 100 posts/week)
>> then maybe we can reconsider our assumptions?
>> 
>> All the best,
>> 
>> Thomas Delteil
>> 
>> On Mon, Jun 18, 2018, 17:30 Pedro Larroy 
>> wrote:
>> 
>>> I agree with Tianqi, Eric and others. We shouldn't dilute the community
>>> with another forum. Disqus is already working and has healthy
>>> participation, you can get an email digest if you so desire. Subscribing to
>>> a mailing list to get a question answered is quite a heavyweight investment
>>> for many people and users who might not have the resources nor mental
>>> bandwidth to receive more email volume in their inboxes.
>>> 
>>> On Mon, Jun 18, 2018 at 10:19 AM Tianqi Chen 
>>> wrote:
>>> 
>>>> The problem of having multiple separate channels of communication is that
>>>> users get confused, and the cost of maintenance goes up(people have to
>>>> watch both). As the current community was at discuss forum and many users
>>>> prefer it, having a mail-list is only a burden we will bring
>>>> 
>>>> Tianqi
>>>> 
>>>> On Mon, Jun 18, 2018 at 9:48 AM, Jim Jagielski  wrote:
>>>> 
>>>>> IMO, that is the wrong way to look at it.
>>>>> 
>>>>> A users@ mailing list is a great, easy, low-cost and low-overhead way
>>> of
>>>>> *increasing* the user community and providing an extra level of
>>> support.
>>>>> Unless there is "strong evidence" that this is NOT the case, I would
>>>>> recommend we create the list.
>>>>> 
>>>>>> On Jun 16, 2018, at 12:28 AM, Tianqi Chen 
>>>>> wrote:
>>>>>> 
>>>>>> So unless there is a strong evidence that our community users prefers
>>>> the
>>>>>> mail-list, I would recommend we keep the current way
>>>>>> 
>>>>>> Tianqi
>>>>>> 
>>>>>> On Fri, Jun 15, 2018 at 9:25 PM, Sergio Fernández >>> 
>>>>> wrote:
>>>>>> 
>>>>>>> Are we targeting just Seattle as our community? I really hope we are
>>>>>>> thinking a bit beyond that...
>>>>>>> 
>>>>>>> On Fri, Jun 15, 2018, 21:22 Tianqi Chen 
>>>>> wrote:
>>>>>>> 
>>>>>>>> I remember last time during the mxnet meetup in Seattle, we did a
>>>>> survey,
>>>>>>>> and most users preferred the current discuss forum. So I would say
>>> we
>>>>>>> stick
>>>>>>>> with that given the user community prefers that
>>>>>>>> 
>>>>>>>> Tianqi
>>>>>>>> 
>>>>>>>> On Fri, Jun 15, 2018 at 9:13 PM, Sergio Fernández <
>>> wik...@apache.org
>>>>> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Then, if everybody agree, let's request the mailing list creation
>>> to
>>>>>>>> INFRA
>>>>>>>>> ;-)
>>>>>>>>> 
>>>>>>>>&g

Re: users@mxnet

[Jim Jagielski]

"Mailing list is an obsolete legacy for old projects"...

Not true. If you don't understand the reason and rationale and *benefits* of 
using a mailing list, and why they are so core to how Apache runs projects, I'd 
be happy to provide some data.

> On Jun 18, 2018, at 2:53 PM, Eric Xie  wrote:
> 
> Neither TF nor Pytorch uses mailing lists though. In fact I can't think of 
> any deep learning community that uses mailing lists. Mailing list is an 
> obsolete legacy for old projects. No point in bringing it into new projects.
> 
> Thanks,
> Eric
> 
> On 2018/06/18 18:42:12, Sebastian  wrote: 
>> I am puzzled by the reluctance of this project to setup a user 
>> mailinglist to be honest.
>> 
>> MXNet has major issues with attracting a community outside of Amazon 
>> (whenever I hear folks talking about deep learning, they usually mention 
>> tensorflow, pytorch and keras, but I rarely hear someone talk about 
>> MXNet). At the same time, there is so much resistance to adopt practices 
>> that are successfully used by many high-profile toplevel projects...
>> 
>> -s
>> 
>> On 18.06.2018 20:37, Timur Shenkao wrote:
>>> Facebook is definitely a bad idea: we will be dependent on third party
>>> provider + unclear who & how manages such group etc.
>>> Forum + Confluence + Slack is  much better then.
>>> 
>>> On Mon, Jun 18, 2018 at 7:17 PM, Ivan Serdyuk 
>>> wrote:
>>> 
>>>> Greetings Barber, Christopher. I had an idea to move out some discussions,
>>>> covering Java and Scala API, to Facebook. So if somewhere exists a local
>>>> JUG or Scala user group - they could reflect the topic of discussion. But
>>>> background stuff could take place on mailing lists, Slack, forum, whatever.
>>>> The reverse mechanism could be used to involve new committers, as well (so
>>>> they would appear as presented newcomers, as for contributions).
>>>> 
>>>> Regards
>>>> Ivan
>>>> 
>>>> On Mon, Jun 18, 2018 at 8:40 PM, Barber, Christopher <
>>>> christopher.bar...@analog.com> wrote:
>>>> 
>>>>> I don't understand why you would want a users mailing list when you
>>>>> already have discussion forums. Users that want to be notified of new
>>>> posts
>>>>> on the forum can configure their notification preferences appropriately.
>>>>> The traffic on the forums is already pretty low. I would think you would
>>>>> not want to dilute that further.
>>>>> 
>>>>> Christopher
>>>>> 
>>>>> On 6/18/18, 1:27 PM, "Jim Jagielski"  wrote:
>>>>> 
>>>>> users@ mailing lists have great societal advantages that one
>>>>> shouldn't ignore...
>>>>> 
>>>>> And it's not like this is the only project with "multiple"
>>>>> communication choices for users. Most, if not all, projects have users@in
>>>>> addition to such supplemental methods as IRC channels, a forum, etc...
>>>> It's
>>>>> about making it easy to have as many users as possible and as many
>>>>> potential ways for users to communicate. It's not confusing; it's
>>>>> empowering :)
>>>>> 
>>>>>> On Jun 18, 2018, at 1:19 PM, Tianqi Chen >>>> 
>>>>> wrote:
>>>>>> 
>>>>>> The problem of having multiple separate channels of communication
>>>> is
>>>>> that
>>>>>> users get confused, and the cost of maintenance goes up(people have
>>>>> to
>>>>>> watch both). As the current community was at discuss forum and many
>>>>> users
>>>>>> prefer it, having a mail-list is only a burden we will bring
>>>>>> 
>>>>>> Tianqi
>>>>>> 
>>>>>> On Mon, Jun 18, 2018 at 9:48 AM, Jim Jagielski 
>>>>> wrote:
>>>>>> 
>>>>>>> IMO, that is the wrong way to look at it.
>>>>>>> 
>>>>>>> A users@ mailing list is a great, easy, low-cost and low-overhead
>>>>> way of
>>>>>>> *increasing* the user community and providing an extra level of
>>>>> support.
>>>>>>> Unless there is "strong evidence" that this is NOT the case, I
>>>> would
>>>>>>> recommend we create the list.
>>>

Re: users@mxnet

[Jim Jagielski]

IMO, that is the wrong way to look at it.

A users@ mailing list is a great, easy, low-cost and low-overhead way of 
*increasing* the user community and providing an extra level of support. Unless 
there is "strong evidence" that this is NOT the case, I would recommend we 
create the list.

> On Jun 16, 2018, at 12:28 AM, Tianqi Chen  wrote:
> 
> So unless there is a strong evidence that our community users prefers the
> mail-list, I would recommend we keep the current way
> 
> Tianqi
> 
> On Fri, Jun 15, 2018 at 9:25 PM, Sergio Fernández  wrote:
> 
>> Are we targeting just Seattle as our community? I really hope we are
>> thinking a bit beyond that...
>> 
>> On Fri, Jun 15, 2018, 21:22 Tianqi Chen  wrote:
>> 
>>> I remember last time during the mxnet meetup in Seattle, we did a survey,
>>> and most users preferred the current discuss forum. So I would say we
>> stick
>>> with that given the user community prefers that
>>> 
>>> Tianqi
>>> 
>>> On Fri, Jun 15, 2018 at 9:13 PM, Sergio Fernández 
>>> wrote:
>>> 
 Then, if everybody agree, let's request the mailing list creation to
>>> INFRA
 ;-)
 
 Marco, I wouldn't do that. Typically developers are also subscribed
>>> there,
 since they may be the most informed people for answering users'
>>> questions.
 But the topics discussed there may not be of the interest for pure
 development purposes. Some discussions will jump from users@ to dev@,
>>> but
 at a different level. So I wouldn't forward one mailing list to the
>>> other.
 
 On Fri, Jun 15, 2018, 21:01 Marco de Abreu
  wrote:
 
> I think nobody was opposed to it in the past, right?
> 
> I'd propose that all emails automatically get copied to dev@ to
>> ensure
> high
> visibility initially. What do you think?
> 
> Sebastian  schrieb am Fr., 15. Juni 2018, 20:51:
> 
>> I have already proposed this many times in the past and would
>>> strongly
>> encourage it.
>> 
>> -s
>> 
>> On 15.06.2018 21:56, Sergio Fernández wrote:
>>> Hi,
>>> 
>>> is there any good reason why the podling doesn't have a users@
 mailing
>> list
>>> yet?
>>> 
>>> Honestly speaking, I'm not a big fan of the other tools the
>> podling
 is
>>> using. Slack and Web forums a cool tools, and I used them a lot
>> in
> other
>>> contexts. But when it comes to transparency and community,
>> mailing
> lists
>>> play a crucial role in the Apache Way.
>>> 
>>> Users are the most important asset a project can have. Even more
>>> than
>>> developers, believe me. So I think it's time to create a users@
> mailing
>>> list for to helping MXNet grow its community beyong the core
>> team.
>>> 
>>> Cheers,
>>> 
>> 
> 
 
>>> 
>> 

Re: Podling Report - Draft

[Jim Jagielski]

AFAIK, I was never a Mentor. I volunteered, but was never
added, which was confirmed by checking via Whimsy.

> On Oct 6, 2017, at 7:40 PM, John D. Ament  wrote:
> 
> 
> 
> On 2017-10-06 00:30, Henri Yandell  wrote: 
>> Done. Markus + Jim left :)
> 
> How was this communicated?  Or maybe when?
> 
>> 
>> On Tue, Oct 3, 2017 at 7:37 PM, Suneel Marthi  wrote:
>> 
>>> The report's been posted to Wiki - mentors please comment and sign-off.
>>> 
>>> On Tue, Oct 3, 2017 at 10:02 PM, Seb Kiureghian 
>>> wrote:
>>> 
 Thanks Chris, fixed:
 https://docs.google.com/document/d/1PGhs96klZB6DXhpK9_
 biPh4-aCm8-bWwFzexnOW_GMA/edit
 
 John, thanks for the suggestion. We will use Confluence for the next
 report.
 
 On Tue, Oct 3, 2017 at 6:11 PM, John D. Ament 
 wrote:
 
> Its great to see community working on a report.  don't forget to post
>>> it
> to the wiki.  In addition, I would like to see you move the creation of
 it
> into ASF infrastructure.  Many projects use Confluence to write it,
 others
> use private SVN repos.
> 
> On 2017-10-03 18:01, Chris Olivier  wrote:
>> Are the line breaks added manually? Might be better if it wraps
> naturally.
>> For example, on my phone, the formatting is scattered at the line
 breaks:
>> 
>> 
>> 
>> On Tue, Oct 3, 2017 at 2:45 PM Seb Kiureghian 
> wrote:
>> 
>>> Henri,
>>> 
>>> I've updated the doc with your suggestions. Please check and sign
 off.
>>> 
>>> 
>>> https://docs.google.com/document/d/1PGhs96klZB6DXhpK9_
> biPh4-aCm8-bWwFzexnOW_GMA/edit
>>> 
>>> On Mon, Oct 2, 2017 at 11:01 AM, Henri Yandell 
> wrote:
>>> 
 Can something be added on the website migration please. Also, not
> sure if
 code migration should be listed as a "important thing for
> graduation" if
 it's done.
 
 Perhaps one of:
 
 * migrate mxnet.io DNS
 * bring website up to Apache standard
 * identify if any more ICLAs or SGAs need signing
 
 
 On Sun, Oct 1, 2017 at 08:58 Seb Kiureghian 
> wrote:
 
> Hi Dev@,
> 
> As you may know, our Podling report is due this Wednesday.
>>> Bhavin
> Thaker
> and I have prepared a draft:
> https://docs.google.com/document/d/1PGhs96klZB6DXhpK9_
> biPh4-aCm8-bWwFzexnOW_GMA/edit
> 
> Feel free to take a look and suggest edits. I'll submit this on
>>> Wednesday.
> 
> Best Regards,
> Seb
> 
 
>>> 
>> 
> 
 
>>> 
>>