Re: Ownership of discuss.mxnet.io

[Michael Wall]

Ticket created, see https://issues.apache.org/jira/browse/INFRA-20493

On Sun, Jul 5, 2020 at 12:35 PM Michael Wall  wrote:
>
> Ok, thanks Sheng.  I will get a ticket created.
>
> Looks like there are releases hosted on dist.mxnet.io and
> repo.mxnet.io as well?  Are we looking for INFRA to host those as
> well?
>
> I see discuss.mxnet.io is now being archived to
> discuss-arch...@mxnet.apache.org.  Is there a similar plan in the
> works for discuss.gluon.ai?
>
> Makes sense on the brand management review, I will hold off until we
> hear from INFRA.
>
> Mike
>
> On Sun, Jul 5, 2020 at 12:31 PM Sheng Zha  wrote:
> >
> > Hi Michael,
> >
> > Thank you for offering to help. Yes, that’s the correct understanding.
> >
> > For brand management, we still haven’t started the review yet. On the other 
> > hand, if the hosting is on Apache infra and PPMC manages the site, then the 
> > site will no longer be owned by a third party.
> >
> > Thanks,
> > Sheng
> >
> > > On Jul 5, 2020, at 9:25 AM, Michael Wall  wrote:
> > >
> > > Did a ticket ever get opened for this?  I can open one, but want to
> > > verify my understanding:
> > >
> > > "We want to explore the possibility of hosting discuss.mxnet.io and
> > > discuss.gluon.ai on Apache infrastructure and hook into Apache user
> > > management."
> > >
> > > Shane also asked if we started a conversation with Brand management.
> > > How can I help there?
> > >
> > > Mike
> > >
> > >> On Thu, Jun 18, 2020 at 6:03 AM Marco de Abreu  
> > >> wrote:
> > >>
> > >> I think we can start by opening a ticket with infra referring to this
> > >> thread.
> > >>
> > >> -Marco
> > >>
> > >> Sheng Zha  schrieb am Do., 18. Juni 2020, 09:45:
> > >>
> > >>> Hi Shane,
> > >>>
> > >>> Thanks for the comment. With my apache hat on, I definitely agree that 
> > >>> it
> > >>> would be better to have such forum on Apache managed infra. I’ve started
> > >>> with discussion archive to ensure that everything is recorded, and I 
> > >>> think
> > >>> I can quickly try to make the backups of that forum accessible to the 
> > >>> PPMC
> > >>> and Apache infra.
> > >>>
> > >>> I think the best way to achieve the goal of continuity, eventually, 
> > >>> would
> > >>> be to host it on Apache infrastructure and have its hosting funded by 
> > >>> ASF.
> > >>> How do we go about requesting this?
> > >>>
> > >>> As for the trademark review, we started working on reviewing the binary
> > >>> distribution usage and are currently focusing on the more pressing issue
> > >>> there. We will get to the domain name usage afterwards.
> > >>>
> > >>> -sz
> > >>>
> > >>>> On Jun 17, 2020, at 6:07 AM, Shane Curcuru  
> > >>>> wrote:
> > >>>>
> > >>>> On 2020/06/12 22:39:10, Marco de Abreu 
> > >>> wrote: ...
> > >>>>> The mxnet.io domain is not under control of the ASF. If we say that a
> > >>> user
> > >>>>> facing platform is managed and endorsed by the PPMC, we should make it
> > >>>>> available under the ASF domain system to further represent the 
> > >>>>> official
> > >>>>> affiliation. Also, it removes a weak link in the chain - e.g. the case
> > >>> when
> > >>>>> the mxnet.io domain ran out and broke quite a bit of stuff. Since the
> > >>> ASF
> > >>>>> offers subdomains for projects, I don't see any reason why not to use
> > >>> them.
> > >>>>
> > >>>> This is the core issue for me, from the larger Apache perspective.
> > >>>> Domain names using Apache marks - especially when they have interactive
> > >>>> traffic about the Apache project itself - work best when the domain 
> > >>>> name
> > >>>> itself is owned by the ASF.  That ensures continuity for the future, in
> > >>>> the case where a party (which includes individual PMC members) stops
> > >>>> contributing to the project.  When the ASF Infra team has direct admin
> > >>>> access to a service or domain, we know that the ASF will be able to
> > >>>> manage it for the future.
> > >>>>
> > >>>> Also, has the PPMC worked with Apache Brand Management on use of
> > >>>> trademarks in domain names?
> > >>>>
> > >>>> https://apache.org/foundation/marks/domains
> > >>>>
> > >>>> --
> > >>>>
> > >>>> - Shane
> > >>>> Director & Member
> > >>>> The Apache Software Foundation
> > >>>

Re: assimilation of mshadow into the MXNet codebase

[Michael Wall]

Yes, to secretary@.  Do you need a template?

Thanks Sheng

Mike

On Sun, Jul 5, 2020 at 12:59 PM Sheng Zha  wrote:
>
> Hi Michael,
>
> Thanks for offering help. I can represent the code donors and file the 
> software grant. Should the filing go to secretary@?
>
> Sheng
>
> > On Jul 5, 2020, at 9:50 AM, Michael Wall  wrote:
> >
> > Is this being tracked in a ticket anywhere?  What help can I offer?
> >
> > Mike
> >
> >> On Fri, Jun 12, 2020 at 6:44 PM Marco de Abreu  
> >> wrote:
> >>
> >> Hi Sheng,
> >>
> >> since this is a "large one off code contribution", the policy [1] states
> >> that they should be brought in through a software grant.
> >>
> >> Best regards,
> >> Marco
> >>
> >> [1]: https://www.apache.org/foundation/how-it-works/legal.html
> >>
> >>> On Fri, Jun 12, 2020 at 11:41 PM Sheng Zha  wrote:
> >>>
> >>> To mentors,
> >>>
> >>> Do we the PPMC need to fill out IP clearance for this code donation?
> >>>
> >>> -sz
> >>>
> >>> On 2019/04/24 21:19:49, Sheng Zha  wrote:
> >>>> The community has agreed to donate mshadow to the mxnet code base. I
> >>> will start the migration and build logic changes soon.
> >>>>
> >>>> -sz
> >>>>
> >>>> On 2019/04/07 21:47:39, Sheng Zha  wrote:
> >>>>> I agree it would make development easier to donate mshadow to mxnet
> >>> code base, since mshadow is only used in MXNet. I support donating the
> >>> mshadow code to mxnet and I started an RFC for this in mshadow [1].
> >>>>>
> >>>>> [1] https://github.com/dmlc/mshadow/issues/373
> >>>>>
> >>>>> -sz
> >>>>>
> >>>>> On 2019/04/06 04:38:19, Tianqi Chen  wrote:
> >>>>>> Technically, mshadow is sufficient for MXNet. Adopting other
> >>> libraries (
> >>>>>> eigen or xtensor) will unnecessarily increase the codebase complexity
> >>>>>> without any additional gains.
> >>>>>>
> >>>>>> Given that mshadow is only used by mxnet. I do support donating it
> >>> into
> >>>>>> mxnet codebase.
> >>>>>> To respect the original mshadow community. I would recommend
> >>> starting a
> >>>>>> community RFC In the mshadow github issue for a week, before we
> >>> start the
> >>>>>> migrating process.
> >>>>>> Also, I would recommend a rebase merge just like the case of
> >>> MXNet.jl code
> >>>>>> base to preserve the contribution history.
> >>>>>>
> >>>>>> Tianqi
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Apr 5, 2019 at 9:25 PM Alfredo Luque
> >>>>>>  wrote:
> >>>>>>
> >>>>>>> Do you have a link to both of these proposals?
> >>>>>>>
> >>>>>>> On Fri, Apr 5, 2019 at 20:14 Anirudh Acharya <
> >>> anirudhk...@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi Pedro,
> >>>>>>>>
> >>>>>>>> mshadow is mostly used for tensor arithmetic. There have been
> >>> discussions
> >>>>>>>> about including it within mxnet. I think it is a good idea.
> >>>>>>>>
> >>>>>>>> As a more long term solution using libraries like eigen to
> >>> perform linear
> >>>>>>>> algebra operations was also suggested by anirudh2290@. I think
> >>> xtensor(
> >>>>>>>> https://github.com/QuantStack/xtensor ) can also be a candidate
> >>> here.
> >>>>>>>>
> >>>>>>>> -
> >>>>>>>> Anirudh
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Fri, Apr 5, 2019 at 7:03 PM Pedro Larroy <
> >>>>>>> pedro.larroy.li...@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi
> >>>>>>>>>
> >>>>>>>>> Some developers have noticed that working in mshadow is
> >>> cumbersome as
> >>>>>>>>> it's a 3rdparty subrepo.
> >>>>>>>>>
> >>>>>>>>> Since mshadow is a bunch of headers which don't have much of
> >>>>>>>>> independent tests / library functionality, me and other
> >>> developers
> >>>>>>>>> believe that it would be good to assimilate this code in the
> >>>>>>>>> repository for ease of contribution and changes without having
> >>> to go
> >>>>>>>>> trough contortions to test PRs that modify mshadow.
> >>>>>>>>>
> >>>>>>>>> Would anybody oppose this change?
> >>>>>>>>>
> >>>>>>>>> Thanks and have a nice weekend.
> >>>>>>>>>
> >>>>>>>>> Pedro.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>

Re: assimilation of mshadow into the MXNet codebase

[Michael Wall]

Is this being tracked in a ticket anywhere?  What help can I offer?

Mike

On Fri, Jun 12, 2020 at 6:44 PM Marco de Abreu  wrote:
>
> Hi Sheng,
>
> since this is a "large one off code contribution", the policy [1] states
> that they should be brought in through a software grant.
>
> Best regards,
> Marco
>
> [1]: https://www.apache.org/foundation/how-it-works/legal.html
>
> On Fri, Jun 12, 2020 at 11:41 PM Sheng Zha  wrote:
>
> > To mentors,
> >
> > Do we the PPMC need to fill out IP clearance for this code donation?
> >
> > -sz
> >
> > On 2019/04/24 21:19:49, Sheng Zha  wrote:
> > > The community has agreed to donate mshadow to the mxnet code base. I
> > will start the migration and build logic changes soon.
> > >
> > > -sz
> > >
> > > On 2019/04/07 21:47:39, Sheng Zha  wrote:
> > > > I agree it would make development easier to donate mshadow to mxnet
> > code base, since mshadow is only used in MXNet. I support donating the
> > mshadow code to mxnet and I started an RFC for this in mshadow [1].
> > > >
> > > > [1] https://github.com/dmlc/mshadow/issues/373
> > > >
> > > > -sz
> > > >
> > > > On 2019/04/06 04:38:19, Tianqi Chen  wrote:
> > > > > Technically, mshadow is sufficient for MXNet. Adopting other
> > libraries (
> > > > > eigen or xtensor) will unnecessarily increase the codebase complexity
> > > > > without any additional gains.
> > > > >
> > > > > Given that mshadow is only used by mxnet. I do support donating it
> > into
> > > > > mxnet codebase.
> > > > > To respect the original mshadow community. I would recommend
> > starting a
> > > > > community RFC In the mshadow github issue for a week, before we
> > start the
> > > > > migrating process.
> > > > > Also, I would recommend a rebase merge just like the case of
> > MXNet.jl code
> > > > > base to preserve the contribution history.
> > > > >
> > > > > Tianqi
> > > > >
> > > > >
> > > > > On Fri, Apr 5, 2019 at 9:25 PM Alfredo Luque
> > > > >  wrote:
> > > > >
> > > > > > Do you have a link to both of these proposals?
> > > > > >
> > > > > > On Fri, Apr 5, 2019 at 20:14 Anirudh Acharya <
> > anirudhk...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Pedro,
> > > > > > >
> > > > > > > mshadow is mostly used for tensor arithmetic. There have been
> > discussions
> > > > > > > about including it within mxnet. I think it is a good idea.
> > > > > > >
> > > > > > > As a more long term solution using libraries like eigen to
> > perform linear
> > > > > > > algebra operations was also suggested by anirudh2290@. I think
> > xtensor(
> > > > > > > https://github.com/QuantStack/xtensor ) can also be a candidate
> > here.
> > > > > > >
> > > > > > > -
> > > > > > > Anirudh
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Apr 5, 2019 at 7:03 PM Pedro Larroy <
> > > > > > pedro.larroy.li...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi
> > > > > > > >
> > > > > > > > Some developers have noticed that working in mshadow is
> > cumbersome as
> > > > > > > > it's a 3rdparty subrepo.
> > > > > > > >
> > > > > > > > Since mshadow is a bunch of headers which don't have much of
> > > > > > > > independent tests / library functionality, me and other
> > developers
> > > > > > > > believe that it would be good to assimilate this code in the
> > > > > > > > repository for ease of contribution and changes without having
> > to go
> > > > > > > > trough contortions to test PRs that modify mshadow.
> > > > > > > >
> > > > > > > > Would anybody oppose this change?
> > > > > > > >
> > > > > > > > Thanks and have a nice weekend.
> > > > > > > >
> > > > > > > > Pedro.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >

Re: Ownership of discuss.mxnet.io

[Michael Wall]

Ok, thanks Sheng.  I will get a ticket created.

Looks like there are releases hosted on dist.mxnet.io and
repo.mxnet.io as well?  Are we looking for INFRA to host those as
well?

I see discuss.mxnet.io is now being archived to
discuss-arch...@mxnet.apache.org.  Is there a similar plan in the
works for discuss.gluon.ai?

Makes sense on the brand management review, I will hold off until we
hear from INFRA.

Mike

On Sun, Jul 5, 2020 at 12:31 PM Sheng Zha  wrote:
>
> Hi Michael,
>
> Thank you for offering to help. Yes, that’s the correct understanding.
>
> For brand management, we still haven’t started the review yet. On the other 
> hand, if the hosting is on Apache infra and PPMC manages the site, then the 
> site will no longer be owned by a third party.
>
> Thanks,
> Sheng
>
> > On Jul 5, 2020, at 9:25 AM, Michael Wall  wrote:
> >
> > Did a ticket ever get opened for this?  I can open one, but want to
> > verify my understanding:
> >
> > "We want to explore the possibility of hosting discuss.mxnet.io and
> > discuss.gluon.ai on Apache infrastructure and hook into Apache user
> > management."
> >
> > Shane also asked if we started a conversation with Brand management.
> > How can I help there?
> >
> > Mike
> >
> >> On Thu, Jun 18, 2020 at 6:03 AM Marco de Abreu  
> >> wrote:
> >>
> >> I think we can start by opening a ticket with infra referring to this
> >> thread.
> >>
> >> -Marco
> >>
> >> Sheng Zha  schrieb am Do., 18. Juni 2020, 09:45:
> >>
> >>> Hi Shane,
> >>>
> >>> Thanks for the comment. With my apache hat on, I definitely agree that it
> >>> would be better to have such forum on Apache managed infra. I’ve started
> >>> with discussion archive to ensure that everything is recorded, and I think
> >>> I can quickly try to make the backups of that forum accessible to the PPMC
> >>> and Apache infra.
> >>>
> >>> I think the best way to achieve the goal of continuity, eventually, would
> >>> be to host it on Apache infrastructure and have its hosting funded by ASF.
> >>> How do we go about requesting this?
> >>>
> >>> As for the trademark review, we started working on reviewing the binary
> >>> distribution usage and are currently focusing on the more pressing issue
> >>> there. We will get to the domain name usage afterwards.
> >>>
> >>> -sz
> >>>
> >>>> On Jun 17, 2020, at 6:07 AM, Shane Curcuru  wrote:
> >>>>
> >>>> On 2020/06/12 22:39:10, Marco de Abreu 
> >>> wrote: ...
> >>>>> The mxnet.io domain is not under control of the ASF. If we say that a
> >>> user
> >>>>> facing platform is managed and endorsed by the PPMC, we should make it
> >>>>> available under the ASF domain system to further represent the official
> >>>>> affiliation. Also, it removes a weak link in the chain - e.g. the case
> >>> when
> >>>>> the mxnet.io domain ran out and broke quite a bit of stuff. Since the
> >>> ASF
> >>>>> offers subdomains for projects, I don't see any reason why not to use
> >>> them.
> >>>>
> >>>> This is the core issue for me, from the larger Apache perspective.
> >>>> Domain names using Apache marks - especially when they have interactive
> >>>> traffic about the Apache project itself - work best when the domain name
> >>>> itself is owned by the ASF.  That ensures continuity for the future, in
> >>>> the case where a party (which includes individual PMC members) stops
> >>>> contributing to the project.  When the ASF Infra team has direct admin
> >>>> access to a service or domain, we know that the ASF will be able to
> >>>> manage it for the future.
> >>>>
> >>>> Also, has the PPMC worked with Apache Brand Management on use of
> >>>> trademarks in domain names?
> >>>>
> >>>> https://apache.org/foundation/marks/domains
> >>>>
> >>>> --
> >>>>
> >>>> - Shane
> >>>> Director & Member
> >>>> The Apache Software Foundation
> >>>

Re: Ownership of discuss.mxnet.io

[Michael Wall]

Did a ticket ever get opened for this?  I can open one, but want to
verify my understanding:

"We want to explore the possibility of hosting discuss.mxnet.io and
discuss.gluon.ai on Apache infrastructure and hook into Apache user
management."

Shane also asked if we started a conversation with Brand management.
How can I help there?

Mike

On Thu, Jun 18, 2020 at 6:03 AM Marco de Abreu  wrote:
>
> I think we can start by opening a ticket with infra referring to this
> thread.
>
> -Marco
>
> Sheng Zha  schrieb am Do., 18. Juni 2020, 09:45:
>
> > Hi Shane,
> >
> > Thanks for the comment. With my apache hat on, I definitely agree that it
> > would be better to have such forum on Apache managed infra. I’ve started
> > with discussion archive to ensure that everything is recorded, and I think
> > I can quickly try to make the backups of that forum accessible to the PPMC
> > and Apache infra.
> >
> > I think the best way to achieve the goal of continuity, eventually, would
> > be to host it on Apache infrastructure and have its hosting funded by ASF.
> > How do we go about requesting this?
> >
> > As for the trademark review, we started working on reviewing the binary
> > distribution usage and are currently focusing on the more pressing issue
> > there. We will get to the domain name usage afterwards.
> >
> > -sz
> >
> > > On Jun 17, 2020, at 6:07 AM, Shane Curcuru  wrote:
> > >
> > > On 2020/06/12 22:39:10, Marco de Abreu 
> > wrote: ...
> > >> The mxnet.io domain is not under control of the ASF. If we say that a
> > user
> > >> facing platform is managed and endorsed by the PPMC, we should make it
> > >> available under the ASF domain system to further represent the official
> > >> affiliation. Also, it removes a weak link in the chain - e.g. the case
> > when
> > >> the mxnet.io domain ran out and broke quite a bit of stuff. Since the
> > ASF
> > >> offers subdomains for projects, I don't see any reason why not to use
> > them.
> > >
> > > This is the core issue for me, from the larger Apache perspective.
> > > Domain names using Apache marks - especially when they have interactive
> > > traffic about the Apache project itself - work best when the domain name
> > > itself is owned by the ASF.  That ensures continuity for the future, in
> > > the case where a party (which includes individual PMC members) stops
> > > contributing to the project.  When the ASF Infra team has direct admin
> > > access to a service or domain, we know that the ASF will be able to
> > > manage it for the future.
> > >
> > > Also, has the PPMC worked with Apache Brand Management on use of
> > > trademarks in domain names?
> > >
> > >  https://apache.org/foundation/marks/domains
> > >
> > > --
> > >
> > > - Shane
> > >  Director & Member
> > >  The Apache Software Foundation
> >

Re: Podling Mxnet Report Reminder - April 2020

[Michael Wall]

LGTM, thanks

On Mon, Mar 30, 2020 at 12:10 AM Sheng Zha  wrote:

> I posted the draft at
> https://cwiki.apache.org/confluence/display/INCUBATOR/April2020#MXNet.
> Suggestions and updates are welcome. Thanks.
>
> -sz
>
> On 2020/03/25 18:18:04, Sheng Zha  wrote:
> > I'm working on a draft now and will report back with link once ready.
> >
> > -sz
> >
> > On 2020/03/20 03:18:09, jmcl...@apache.org wrote:
> > > Dear podling,
> > >
> > > This email was sent by an automated system on behalf of the Apache
> > > Incubator PMC. It is an initial reminder to give you plenty of time to
> > > prepare your quarterly board report.
> > >
> > > The board meeting is scheduled for Wed, 15 April 2020, 10:30 am PDT.
> > > The report for your podling will form a part of the Incubator PMC
> > > report. The Incubator PMC requires your report to be submitted 2 weeks
> > > before the board meeting, to allow sufficient time for review and
> > > submission (Wed, April 01).
> > >
> > > Please submit your report with sufficient time to allow the Incubator
> > > PMC, and subsequently board members to review and digest. Again, the
> > > very latest you should submit your report is 2 weeks prior to the board
> > > meeting.
> > >
> > > Candidate names should not be made public before people are actually
> > > elected, so please do not include the names of potential committers or
> > > PPMC members in your report.
> > >
> > > Thanks,
> > >
> > > The Apache Incubator PMC
> > >
> > > Submitting your Report
> > >
> > > --
> > >
> > > Your report should contain the following:
> > >
> > > *   Your project name
> > > *   A brief description of your project, which assumes no knowledge of
> > > the project or necessarily of its field
> > > *   A list of the three most important issues to address in the move
> > > towards graduation.
> > > *   Any issues that the Incubator PMC or ASF Board might wish/need to
> be
> > > aware of
> > > *   How has the community developed since the last report
> > > *   How has the project developed since the last report.
> > > *   How does the podling rate their own maturity.
> > >
> > > This should be appended to the Incubator Wiki page at:
> > >
> > > https://cwiki.apache.org/confluence/display/INCUBATOR/April2020
> > >
> > > Note: This is manually populated. You may need to wait a little before
> > > this page is created from a template.
> > >
> > > Note: The format of the report has changed to use markdown.
> > >
> > > Mentors
> > > ---
> > >
> > > Mentors should review reports for their project(s) and sign them off on
> > > the Incubator wiki page. Signing off reports shows that you are
> > > following the project - projects that are not signed may raise alarms
> > > for the Incubator PMC.
> > >
> > > Incubator PMC
> > >
> >
>

Re: CCLA for MXNET

[Michael Wall]

I am going to include Justin to get his take on this.  Justin, does this
need to go to legal?

Thanks

Mike

On Mon, Jan 13, 2020 at 10:13 AM Gil Yehuda 
wrote:

> Thanks,
> I believe that we have a CCLA between *Verizon Media* (was Yahoo) and
> Apache. This however is a contribution from *Verizon* (the parent
> company) and I don't think they've had a relationship with Apache. So they
> are asking my assistance to get everything in place.
>
> I believe they will have contributions, yet I don't know if any will want
> to seek committer status. All in time, as they get more involved in the
> project, I guess. But I wanted to prepare what they might need. Should I
> sign a CCLA on the part of Verizon? (I am authorized by Verizon Legal to do
> so.)
>
> Gil Yehuda: I help with external technology engagement
>
> From the Open Source Program Office
> <https://developer.yahoo.com/opensource/docs/> at Yahoo --> Oath - ->
> Verizon Media
>
>
>
> On Sun, Jan 12, 2020 at 10:33 AM Michael Wall  wrote:
>
>> Hi Gil,
>>
>> Do you have code already that you are looking to contribute?  Or are you
>> looking to assign people to issues?
>>
>> Take a look at
>> https://www.apache.org/licenses/contributor-agreements.html.  Typically
>> a CLA is not needed for someone to start making contributions.  An ICLA is
>> required for someone to join Apache and become committer.  For your
>> situation, it sounds like it you may want to get the Corporate CLA in
>> place.  Also take a look at https://www.apache.org/licenses/cla-faq.html
>>
>> Mike
>>
>>
>>
>> On Fri, Jan 10, 2020 at 12:15 AM Gil Yehuda
>>  wrote:
>>
>>> Dear MXNet Dev team
>>> I have a team at Verizon who would like to start contributing code to
>>> MXNet. In preparation, would you need a CCLA in place between Verizon and
>>> Apache listing their names? and ICLAs from them? if so I'll be glad to
>>> make
>>> this happen. I didn't see the CLA indicated on the contributing
>>> documentation in the repo, so I'm asking just in case. Thanks
>>>
>>> Gil Yehuda: I help with external technology engagement
>>>
>>> From the Open Source Program Office
>>> <https://developer.yahoo.com/opensource/docs/> at Yahoo --> Oath - ->
>>> Verizon Media
>>>
>>

Re: CCLA for MXNET

[Michael Wall]

Hi Gil,

Do you have code already that you are looking to contribute?  Or are you
looking to assign people to issues?

Take a look at https://www.apache.org/licenses/contributor-agreements.html.
Typically a CLA is not needed for someone to start making contributions.
An ICLA is required for someone to join Apache and become committer.  For
your situation, it sounds like it you may want to get the Corporate CLA in
place.  Also take a look at https://www.apache.org/licenses/cla-faq.html

Mike



On Fri, Jan 10, 2020 at 12:15 AM Gil Yehuda
 wrote:

> Dear MXNet Dev team
> I have a team at Verizon who would like to start contributing code to
> MXNet. In preparation, would you need a CCLA in place between Verizon and
> Apache listing their names? and ICLAs from them? if so I'll be glad to make
> this happen. I didn't see the CLA indicated on the contributing
> documentation in the repo, so I'm asking just in case. Thanks
>
> Gil Yehuda: I help with external technology engagement
>
> From the Open Source Program Office
>  at Yahoo --> Oath - ->
> Verizon Media
>

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

[Michael Wall]

Cc'ing dev@mxnet.i.a.o this time

Mike

On Tue, Sep 24, 2019, 17:47 Michael Wall  wrote:

> FYI, the release notes link to
> https://mxnet.incubator.apache.org/install/index.html which is returning
> a 404.  Maybe related to the new website?  Same for
> https://mxnet.incubator.apache.org/versions/master/install/index.html which
> is the first result of my Google search for 'install mxnet'.
>
> Mike
>
> On Tue, Sep 24, 2019 at 1:26 AM Tao Lv  wrote:
>
>> Thank you Mike! I'm sorry for missing your vote on dev@.
>>
>> To other MXNet mentors, may I have your opinion on this vote?
>>
>> Thanks,
>> -tao
>>
>> On Sun, Sep 22, 2019 at 11:54 PM Michael Wall  wrote:
>>
>> > +1 (binding)
>> >
>> > - Built from src without opencv
>> > - sha512 signature are good
>> > - gpg key for release manager in
>> >   https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS and gpg
>> > --verify
>> >   passes
>> > - many but not all of the license issues from the 1.5.0 release have
>> been
>> >   addressed, see
>> >
>> >
>> https://lists.apache.org/thread.html/5365cdab7dee08d220e32decc76fd54aa05e29bc891c416828cb64d2@%3Cgeneral.incubator.apache.org%3E
>> >   Ticket tracking these is
>> >   https://github.com/apache/incubator-mxnet/issues/15542
>> >   where all the license issues are being tracked for the 1.6 release
>> >
>> >
>> > On Sun, Sep 22, 2019 at 11:34 AM Tao Lv  wrote:
>> >
>> > > Dear community,
>> > >
>> > > This is a call for a releasing Apache MXNet (incubating) 1.5.1,
>> release
>> > > candidate 0.
>> > >
>> > > Apache MXNet (incubating) community has voted and approved the
>> release.
>> > >
>> > > Vote thread:
>> > >
>> > >
>> > >
>> >
>> https://lists.apache.org/thread.html/32f9e98d3409c84c01703ce89843510b0f5c47a54d6d5327f6279050@%3Cdev.mxnet.apache.org%3E
>> > >
>> > > Result thread:
>> > >
>> > >
>> >
>> https://lists.apache.org/thread.html/964c0a228c2d6bfbb8428be8c1454f660b8b4a684d334cfbdf317f57@%3Cdev.mxnet.apache.org%3E
>> > >
>> > >
>> > > The source tarball, including signatures, digests, etc. can be found
>> at:
>> > >
>> > > https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.5.1.rc0/
>> > >
>> > > The tag to be voted upon is 1.5.1.rc0:
>> > > https://github.com/apache/incubator-mxnet/releases/tag/1.5.1.rc0
>> > >
>> > > The release hash is  c9818480680f84daa6e281a974ab263691302ba8  :
>> > >
>> > >
>> >
>> https://github.com/apache/incubator-mxnet/commit/c9818480680f84daa6e281a974ab263691302ba8
>> > >
>> > >
>> > > KEYS file available:
>> > >
>> > > https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS
>> > >
>> > > For information about the contents of this release, see:
>> > > https://cwiki.apache.org/confluence/display/MXNET/1.5.1+Release+Notes
>> > >
>> > > The vote will be open for 72 hours.
>> > >
>> > > [ ] +1 release this package as #
>> > > [ ] +0 no opinion
>> > > [ ] -1 do not release this package because...
>> > >
>> > >
>> > > Best Regards,
>> > >
>> > > -tao
>> > >
>> >
>>
>

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

[Michael Wall]

Tao,

I can take a look tonight if you want to wait.

Mike

On Fri, Sep 20, 2019 at 10:45 AM Tao Lv  wrote:

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

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

[Michael Wall]

Will make time to review before Sun.  Thanks for the note.

Mike

On Wed, Jul 10, 2019 at 1:52 PM Lai Wei  wrote:

> Dear MXNet mentors,
>
> Since the vote has passed on dev, I started voting on general@
>
> Justin is asking did any mentors vote on the release[1]. Could you please
> help with the vote on general@ ?
> Really appreciate it, thanks a lot!
>
> [1]
>
> https://mail-archives.apache.org/mod_mbox/incubator-general/201907.mbox/%3c380abca2-01e5-4200-bed1-b943a223e...@classsoftware.com%3e
>
>
> Best Regards
>
> Lai
>
>
> On Wed, Jul 10, 2019 at 2:19 AM Lai Wei  wrote:
>
> > Dear MXNet community,
> >
> > I'm happy to announce the results of the vote.
> >
> > This vote passes with 5 +1 votes (3 binding) and no 0 or -1 votes.
> >
> > +1 votes
> > * Sheng Zha / binding
> > * Qing Lan / binding
> > * Sandeep Krishnamurthy / binding
> > * Przemysław Trędak
> > * Patric Zhao
> >
> > 0 votes
> > * No votes
> >
> > -1 votes
> > * No votes
> >
> > Vote thread can be found here [1]. The list of members can be found here
> > [2].
> >
> > I'll continue with the release process and the release announcement will
> > follow in the next few days.
> >
> >
> > Best regards,
> > Lai
> >
> > [1]
> >
> https://lists.apache.org/thread.html/50fe473a3e03c891caccb8cae8e5195bb740a4758f7688790dff70df@%3Cdev.mxnet.apache.org%3E
> > [2] http://incubator.apache.org/projects/mxnet.html
> >
> >
> >
> >
> > Best Regards
> >
> > Lai
> >
>

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

[Michael Wall]

So is the plan option 3?  I have seen tickets fixing licenses, so good work
there.  When a vote is started on dev@mxnet.a.o, include wording about not
waiting the full 72 hours since this is just updating licensing.  Get as
many +1 votes as you can on both the release and not waiting then move on
to IPMC.  The vote on general@incubator.a.o should still stay open 72
hours.  I will look at it as soon as it is posted, but maybe reach out to
the other mentors directly asking for their help to review as soon as it is
out.  The goal is to have the 3 or more +1 votes and more positive then
negative as soon as the 72 hours hits.

Mike

On Wed, Feb 13, 2019 at 2:44 AM Justin Mclean 
wrote:

> forgot to CC dev
>
> > Begin forwarded message:
> >
> > From: Justin Mclean 
> > Subject: Re: [RESTARTING][VOTE] Release Apache MXNet (incubating)
> version 1.4.0.rc2
> > Date: 13 February 2019 at 6:43:48 pm AEDT
> > To: Michael Wall 
> >
> > Hi,
> >
> >> Option 1:
> >> Do nothing.  I don't know how a RESTARTED vote works.
> >
> > I don’t believe there is such a concept.
> >
> >> Option 2:
> >> Start another vote thread on general@incubator.a.o pointing to the
> original vote thread on dev@mxnet.a.o and the canceled vote thread.
> >
> > It may end up with the same outcome.
> >
> >> Option 3:
> >> 1 - Fix the header issues.
> > 
> >> 3 - Start a vote thread on general@incubator.a.o pointing to the new
> vote thread from step 2.  Will likely need to be open 72 hours.
> >
> > Just be aware it can take longer, sometime much longer, to get the 3 +1
> IPMC votes.
> >
> >> Tough position to be in with Horovod being released.
> >
> > Which show the risk of tying in your release cycle with a non Apache
> product. IMO you need to be independent of 3rd party releases and not tied
> to their milestones. If they wanted to include a particular unreleased
> version of ASF software, you should started the release a long time ahead
> of time just in case problems were encountered issues.This probably
> wouldn't be an issue if you made more frequent releases, it’s easier to
> check compliance with frequent releases so the 3rd party could just take
> the last good release and go with that.
> >
> > Thanks,
> > Justin
>
>

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

[Michael Wall]

Hi Qing,

I see 3 options

Option 1:
Do nothing.  I don't know how a RESTARTED vote works.  Steffen counted the
binding votes from the before it was restarted.  Unsure if that actually
works.  There has been one +1 votes since the restart, but it is
non-binding as best I can tell even though it labeled as binding.  To be a
binding vote for the general@incubator.a.o VOTE you must be on the
Incubator PMC or IPMC.  Users on the MXNet Podling PMC or PPMC have a
binding vote only on the dev@mxnet VOTE thread.   See
https://incubator.apache.org/policy/incubation.html#releases.  In addition,
those binding +1 votes may need to be changes based on
http://www.apache.org/legal/release-policy.html#release-approval which reads

"Before casting +1 binding votes, individuals are REQUIRED to download all
signed source code packages onto their own hardware, verify that they meet
all requirements of ASF policy on releases as described below, validate all
cryptographic signatures, compile as provided, and test the result on their
own platform."

Luciano's -1 was because the release does not meet the licensing policy at
http://www.apache.org/legal/release-policy.html#license-headers

For this reason, I can not give a +1 on the general@incubator.a.o VOTE
thread.  Sorry, that is why I have not voted.

Option 2:
Start another vote thread on general@incubator.a.o pointing to the original
vote thread on dev@mxnet.a.o and the canceled vote thread.  Likely that
need to be open for 72 hours unless the IPMC agrees otherwise.  I list this
because I don't know if a RESTART recounting votes from a prior thread is
valid.  But this option has the same risk of not being approved for the
reasons listed above.

Option 3:
1 - Fix the header issues.  I dug a little more, and the excludes file at
https://github.com/apache/incubator-mxnet/blob/v1.4.x/tests/nightly/apache_rat_license_check/rat-excludes
is
overly broad and excludes files from the check that should have license
headers, again per
http://www.apache.org/legal/release-policy.html#license-headers
2 - Start a vote thread on dev@mxnet.a.o.  Doesn't have to be open 72 hours
according to Justin's note if the PPMC agrees.  Expect this would need to
be documented on the mailing list, but could be part of the vote I think.
3 - Start a vote thread on general@incubator.a.o pointing to the new vote
thread from step 2.  Will likely need to be open 72 hours.

Clearly option 1 would be faster, but the risk is the vote not passing.
Option 2 may not be needed if the restart in option 1 is valid.  Option 3
is the most correct I think according to what I read in ASF policy.  But
rushing a vote does have risks, such as less testing on the code being
released.

To make this more confusing, the VOTE thread is showing up on both
dev@mxnet.a.o and general@incubator.a.o.  There is an additional +1 vote on
the dev@mxnet.a.o list that doesn't show up on the general@incubator, but
this too is non binding best I can tell.

Tough position to be in with Horovod being released.  Nothing in ASF policy
makes allowances for such an event that I could find.  Perhaps we should
ask for more clarification on general@incubator.a.o to get more thoughts
from the IPMC.

Mike

On Tue, Feb 12, 2019 at 5:53 PM Qing Lan  wrote:

> Hi Michael,
>
> Could you please guide how to proceed with this? Given that we have a
> possibility of announcing MXNet support in Horovod with their next release
> and this would help MXNet increase our visibility.
>
> Thanks,
> Qing
>
> On 2/12/19, 2:16 PM, "Michael Wall"  wrote:
>
> Team,
>
> Here is my read on the situation.  The vote has been canceled.
> Justin's
> point was that a -1 doesn't mean you must cancel a vote for the
> reasons he
> outlined.  But here the vote needs to be restarted and the issue
> Luciano
> found needs to be addressed.
>
> That issue is that there are files in MXNet source tree that do not
> have
> the required licenses headers,
> http://www.apache.org/legal/release-policy.html#license-headers.  For
> example, the top level README.md is missing the header
>
> https://raw.githubusercontent.com/apache/incubator-mxnet/master/README.md.
> Excluding 3rd party files from the RAT check is fine, but not files
> originating from the MXNet repo.
>
> It would be good to know exactly how Luciano ran the RAT check, cc'd.
> Here
> is a link to the thread
>
> https://lists.apache.org/thread.html/51e9ab05edae2089c74a253000a92d5aa5c6406f54e5bd0a0b3c3879@%3Cgeneral.incubator.apache.org%3E
> .
>
> Justin's other point, aIso cc'd, was that the vote with the podling
> doesn't
> have to take 72 hours before going to the incubator list.
>
> I realize this is not what everyone is pushing for, so interested in
> other's thoughts.  Especially other mentors.
>
&

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

[Michael Wall]

Team,

Here is my read on the situation.  The vote has been canceled.  Justin's
point was that a -1 doesn't mean you must cancel a vote for the reasons he
outlined.  But here the vote needs to be restarted and the issue Luciano
found needs to be addressed.

That issue is that there are files in MXNet source tree that do not have
the required licenses headers,
http://www.apache.org/legal/release-policy.html#license-headers.  For
example, the top level README.md is missing the header
https://raw.githubusercontent.com/apache/incubator-mxnet/master/README.md.
Excluding 3rd party files from the RAT check is fine, but not files
originating from the MXNet repo.

It would be good to know exactly how Luciano ran the RAT check, cc'd.  Here
is a link to the thread
https://lists.apache.org/thread.html/51e9ab05edae2089c74a253000a92d5aa5c6406f54e5bd0a0b3c3879@%3Cgeneral.incubator.apache.org%3E
.

Justin's other point, aIso cc'd, was that the vote with the podling doesn't
have to take 72 hours before going to the incubator list.

I realize this is not what everyone is pushing for, so interested in
other's thoughts.  Especially other mentors.

Mike

On Tue, Feb 12, 2019 at 4:47 PM Aaron Markham 
wrote:

> +1
> I disagree about 3rd party considerations. This is an ecosystem after all.
> The distributed training story is quite nice with Horovod. Given my
> interaction with tensorflow with  Horovod and dynamic training with MXNet
> and the kvstore, this new route is, IMO, easier to setup and manage.
> I see the benefit for getting it out there sooner than later, and market
> timings are important to the project and adoption. If Uber's announcement
> drives traffic to MXNet, but then people can't set it up with a stable
> release package, there's a lost opportunity for growing the community. Why
> miss the opportunity for a RAT license?
>
> On Tue, Feb 12, 2019, 13:14 Dave Fisher  wrote:
>
> > Hi -
> >
> > Third party vendor considerations do not matter. Are you voting +1 with
> > your Apache hat on or your Amazon hat?
> >
> > Regards,
> > Dave
> >
> > > On Feb 11, 2019, at 10:16 PM, Lin Yuan  wrote:
> > >
> > > +1 binding
> > > Horovod is going to release it's 0.16.0 in the coming week with MXNet
> > > integration. We need to release 1.4.0 which includes all the
> dependencies
> > > for Horovod integration.
> > >
> > > Best,
> > >
> > > Lin
> > >
> > > On Mon, Feb 11, 2019 at 9:30 PM Steffen Rochel <
> steffenroc...@gmail.com>
> > > wrote:
> > >
> > >> Dear community -
> > >> based on Justin's and community feedback I'm suggesting to restart the
> > >> vote.
> > >> Current status:
> > >> binding votes:
> > >> +1: 2 votes (Henri, Jason)
> > >> -1:  1 vote (Luciano)
> > >>
> > >> non-binding:
> > >> +1: 1 vote (Kellen)
> > >>
> > >> The community is investigating feedback from Luciano that the
> exclusion
> > >> file is to broad and potentially missing files which can and must have
> > >> apache license headers not to be checked.
> > >>
> > >> Regards,
> > >> Steffen
> > >>
> > >>
> > >>
> > >>
> > >> On Mon, Feb 11, 2019 at 10:08 AM Hagay Lupesko 
> > wrote:
> > >>
> > >>> Based on Justin's feedback, can we resume the vote instead of
> > cancelling
> > >>> it?
> > >>>
> > >>> On Mon, Feb 11, 2019 at 12:02 AM Justin Mclean <
> > jus...@classsoftware.com
> > >>>
> > >>> wrote:
> > >>>
> >  Hi,
> > 
> >  In future don’t be so hasty to cancel a release vote, people mind
> can
> > >> be
> >  changed and a -1 is not a veto on a release.
> > 
> >  Thanks,
> >  Justin
> > 
> > 
> > 
> -
> >  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >  For additional commands, e-mail: general-h...@incubator.apache.org
> > 
> > 
> > >>>
> > >>
> >
> >
>

Re: [Article] Object Detection with Clojure MXNet

[Michael Wall]

Great article, thanks for sharing Carin.

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

Re: Proposal for a recurrent architecture meeting and long term direction

[Michael Wall]

Thanks for that reminder Isabel.  As a recently added mentor, I have been
struggling to understand all the interactions on MXNet.  Besides the user,
dev and private mailing lists, I am trying to watch

- Two forums at https://discuss.mxnet.io/ and https://discuss.gluon.ai/
(although I can't read Chinese so really only 1 I guess)
- Multiple lists on slack to include
https://the-asf.slack.com/messages/C7FN4FCP9,
https://the-asf.slack.com/messages/CEE9X9WN7,
https://the-asf.slack.com/messages/CBS4K0CPJ
- https://cwiki.apache.org/confluence/display/MXNET
- Issues https://github.com/apache/incubator-mxnet/issues
- Meetups and hangouts as noted on
https://cwiki.apache.org/confluence/display/MXNET/Meetups+and+Hangouts

I love all the effort and collaboration.  So much inertia, so many amazing
things in motion.  But I am having a hard time tracking it all and I worry
about what is not making it back to the public lists.  I have often heard
something to the effect, "If it doesn't happen on the mailing list, it
doesn't happen".  To quote
http://www.apache.org/dev/pmc.html#mailing-list-naming-policy.

"Decisions SHALL NOT be made in other mediums, like IRC or at conferences;
rather discussions from such places must be brought back to the appropriate
mailing list for all participants to discuss and decide upon."

I wonder if others have trouble tracking it all too and if so, what effect
that has on the community?  Is this something that needs to be addressed
before MXNet can graduate the incubator?

Interested in others thoughts.

Mike

On Sat, Jan 19, 2019 at 1:11 PM Isabel Drost-Fromm 
wrote:

>
>
> Am 19. Januar 2019 16:35:58 MEZ schrieb Pedro Larroy <
> pedro.larroy.li...@gmail.com>:
> > We talked with Timur about graphcore accelerators, and
> >seems other people also missed the meeting
>
> Meetings like this always should be optional, what's more important: It
> must be possible to follow the project from subscribing to its mailing
> lists only.
>
>
> >For next meeting I will send an agenda of topics to discuss in advance.
>
> That seems like a good idea to motivate ppl to participate.
>
> What's more important though is bringing discussions back here on list so
> everyone can participate (at the very minimum, potential decisions have to
> be brought back here. It helps with building transparency, community and
> ultimately trust to also pro actively bring a brief summary of other
> discussions here).
>
> Isabel
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>

Re: Incubator Podling Report (Due 2nd January)

[Michael Wall]

Thanks Steffen and Haibin.

On Wed, Jan 2, 2019 at 3:09 PM Steffen Rochel 
wrote:

> Dear MXNet community -
> Haibin and I are working on the MXNet report. See a draft at
> https://wiki.apache.org/incubator/January2019.
> Please provide feedback by 5pm PST today, so the report can be submitted in
> time by EOB today.
>
> Thanks,
> Steffen
>
> On Tue, Jan 1, 2019 at 10:39 PM Justin Mclean  wrote:
>
> > Hi,
> >
> > The report is due today. [1] If you cannot report this month, it will eb
> > noted in teh board report and you'll be asked to report next month.
> >
> > Thanks,
> > Justin
> >
> > 1. https://wiki.apache.org/incubator/January2019
> >
>

Re: Slack invite hotlink

[Michael Wall]

I am not sure honestly.  I read that as the token expires in the 30 days
and the shortened URL is permanent and will always point to the token even
after it expires.

There has been some discussion in the #asfinfra channel on slack[1].  If I
figure anything out I'll report back.

[1] https://the-asf.slack.com/archives/CBX4TSBQ8/p1544485682181600

On Tue, Dec 11, 2018 at 2:31 PM Marco de Abreu 
wrote:

> Hi Mike,
>
> thanks for the heads up and linking the ticket. In there, Chris stated that
> he converted the link to a permanent one:
> > The link in your shortened URL is now permanent.
>
> Does that address your concerns?
>
> Best regards,
> Marco
>
> On Tue, Dec 11, 2018 at 6:19 PM Michael Wall  wrote:
>
> > Marco,
> >
> > Seems like that link is only good for 30 days.  See
> > https://issues.apache.org/jira/browse/INFRA-17152.
> >
> > Mike
> >
> >
> > On Tue, Dec 11, 2018 at 12:01 PM Marco de Abreu  >
> > wrote:
> >
> > > Hey everyone,
> > >
> > > there's a hotlink [1] that allows people to join Apaches Slack server
> > > directly, I found it here [2]. They would then still have to join the
> > > #mxnet channel though. Should we maybe add this to the instructions on
> > the
> > > website?
> > >
> > > Best regards,
> > > Marco
> > >
> > > [1]: https://s.apache.org/slack-invite
> > > [2]: https://beam.apache.org/community/contact-us/
> > >
> >
>

Re: Slack invite hotlink

[Michael Wall]

Marco,

Seems like that link is only good for 30 days.  See
https://issues.apache.org/jira/browse/INFRA-17152.

Mike


On Tue, Dec 11, 2018 at 12:01 PM Marco de Abreu 
wrote:

> Hey everyone,
>
> there's a hotlink [1] that allows people to join Apaches Slack server
> directly, I found it here [2]. They would then still have to join the
> #mxnet channel though. Should we maybe add this to the instructions on the
> website?
>
> Best regards,
> Marco
>
> [1]: https://s.apache.org/slack-invite
> [2]: https://beam.apache.org/community/contact-us/
>

Re: Apache Infra tickets for MXNet

[Michael Wall]

Thanks for working through that with infra Marco.  I think the process you
outlined is good and being able to submit tickets without mentor approval
is good for the project.

Whoever puts the process on the wiki please reply with a link.

Mike

On Thu, Nov 29, 2018 at 11:45 PM Steffen Rochel 
wrote:

> Thanks Marco. Cwiki seems a good place to document the policy.
> Steffen
>
> On Thu, Nov 29, 2018 at 8:06 PM Marco de Abreu
>  wrote:
>
> > Hello everyone,
> >
> > I have just had a nice conversation with Greg Stein, VP of Apache Infra,
> > about the topic of creating tickets against Apache Infra.
> >
> > In the past, we had the restriction that only IPMC members (speak,
> mentors)
> > were allowed to file tickets against Apache Infra. This was due past
> issues
> > where tickets have been created without previous discussions on dev@ and
> > from people who were not PPMC members, thus creating too much churn.
> >
> > During the last year, the MXNet community has shown that we are able to
> > adhere to the Apache ways. Thus the restrictions are being lifted and the
> > following policy get set in place:
> >
> > - Only PPMC members are allowed to create tickets (if you can see
> > priv...@mxnet.apache.org, you're good to go)
> > - Committers are not allowed to create tickets (if you have write access
> to
> > GitHub but can't see priv...@mxnet.apache.org, you're not a PPMC member
> > but
> > a committer)
> > - Contributors are not allowed to create tickets (if you're neither a
> PPMC
> > member, nor a committer, then you're a contributor)
> > - There always has to be a dev@ thread before a ticket can be created.
> > That
> > thread has to be linked in that said ticket.
> > - Always search for a solution yourself (self-service) before engaging
> with
> > Apache Infra.
> >
> > I'm not sure about a good place to document these guidelines. If somebody
> > has a good idea where we should write them down, please feel free to drop
> > me a link and I'll paste them in there.
> >
> > Thanks everybody for the great collaboration around Apache Infra tickets!
> > This was a prime example of a community working together.
> >
> > Best regards,
> > Marco
> >
>

Re: [Discussion] Separating PMC and Committership

[Michael Wall]

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

Re: MXNet Podling Report - October

[Michael Wall]

Looks good to me. Not sure that Justin is subscribed to the dev so
including him explicitly here.  Thanks Haibin.

Mike

On Thu, Oct 4, 2018 at 8:12 PM Haibin Lin  wrote:

> Hi Justin and Michael,
>
> I updated the report with the links to the tutorial summaries:
> June -
>
> https://lists.apache.org/thread.html/52f88e9dc7a6a2a1dfa5ad41c469fe2cdd1209a0be2eb345bc2f9a96@%3Cuser.mxnet.apache.org%3E
> July -
>
> https://lists.apache.org/thread.html/dea9184350f2fe87ce450722ead28072f763196045f39859190f83f8@%3Cuser.mxnet.apache.org%3E
> August - https://discuss.mxnet.io/t/apache-mxnet-digest-august-2018/1863
>
> Justin, the length of the permanent link is longer than 76 characters.
> Would this be an issue?
>
> Best,
> Haibin
>
>
>
> On Thu, Oct 4, 2018 at 1:16 PM Haibin Lin 
> wrote:
>
> > Hi Justin,
> >
> > Thanks for the notice. I've reformatted the MXNet section to have at most
> > 76 characters per line. Sorry about the last minute update.
> >
> > Best,
> > Haibin
> >
> > On Thu, Oct 4, 2018 at 12:59 PM Justin Mclean 
> wrote:
> >
> >> Hi,
> >>
> >> I noticed you have edited the report after the due date and have broken
> >> the formatting a little after I formatted it. Each line must have a
> maximum
> >> of 76 characters, would you mind fixing your section of the report?
> >>
> >> Thanks,
> >> Justin
> >>
> >
>

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

[Michael Wall]

Great, glad it worked.  I learned something too.

On Thu, Oct 4, 2018, 22:09 Marco de Abreu
 wrote:

> Oh nice, great catch Michael and Carin! I just learned something new,
> thanks :)
>
> I guess we're all set then, right? Thanks a lot, everyone!
>
> -Marco
>
> Carin Meier  schrieb am Fr., 5. Okt. 2018, 02:47:
>
> > Micheal,
> >
> > Thanks. You were right! I could merge.
> >
> > The PR shows up now as merged
> > https://github.com/apache/incubator-mxnet/pull/10149
> > My merge commit is here
> > https://github.com/apache/incubator-mxnet/commits/master
> >
> > Thanks again for the help.
> >
> > - Carin
> >
> >
> >
> > On Thu, Oct 4, 2018 at 8:09 PM Michael Wall  wrote:
> >
> > > I would try the merge locally and then inspect the result closely to
> make
> > > sure it looks like what you want.  If it looks good, you could try
> > pushing
> > > to master.  If you can't push, then we know but I "think" protected
> just
> > > means you can't force push in this case based on
> > > https://issues.apache.org/jira/browse/INFRA-15233 which links to
> > > https://home.apache.org/~pono/mxnet.png.  Maybe I have only tried that
> > > with
> > > repo that own though.
> > >
> > > I did find at least one ticket where a team asked for merge commits to
> be
> > > enabled, https://issues.apache.org/jira/browse/INFRA-16690.  But I
> think
> > > they intend for it to stay that way.  Is that what the community would
> > want
> > > for the MXNet repo?  Or would you want to enable it for this and
> disable
> > it
> > > again?
> > >
> > >
> > > On Thu, Oct 4, 2018 at 7:29 PM Carin Meier 
> wrote:
> > >
> > > > 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 <
> carinme...@gmail.com
> > >
> > > > > 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 <
> >

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

[Michael Wall]

I would try the merge locally and then inspect the result closely to make
sure it looks like what you want.  If it looks good, you could try pushing
to master.  If you can't push, then we know but I "think" protected just
means you can't force push in this case based on
https://issues.apache.org/jira/browse/INFRA-15233 which links to
https://home.apache.org/~pono/mxnet.png.  Maybe I have only tried that with
repo that own though.

I did find at least one ticket where a team asked for merge commits to be
enabled, https://issues.apache.org/jira/browse/INFRA-16690.  But I think
they intend for it to stay that way.  Is that what the community would want
for the MXNet repo?  Or would you want to enable it for this and disable it
again?


On Thu, Oct 4, 2018 at 7:29 PM Carin Meier  wrote:

> 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 <
> plus...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > >> Sorry, here is the image: https://imgur.com/V5wd2XB
> > > > > >>
> > > > > >> And here is the github document on the 3 different merge options
> &

Re: MXNet Podling Report - October

[Michael Wall]

Hi Haibin,

A couple of things I thought of when reviewing the report
1 - No answer for the question "Any issues that the Incubator PMC (IPMC) or
ASF Board wish/need to be aware of?"
2 - What are the links to the medium blog, the youtube channel and the
twitter account?
3 - Where did the 62 tutorials come from?  Mostly my own interest to see
them.
4 - How were the github stats calculated?  For Sep 2018 issues created, the
report read 87 but I come up with 112 (the sum of open and closed  from
https://github.com/apache/incubator-mxnet/issues?utf8=%E2%9C%93=is%3Aissue+created%3A2018-09-01..2018-09-30+).
For Sep 2018 issues closed the report read 124 where I get 110 (
https://github.com/apache/incubator-mxnet/issues?utf8=%E2%9C%93=is%3Aissue+closed%3A2018-09-01..2018-09-30+).
But that is only for the incubator-mxnet repo, it doesn't include
incubator-mxnet-site or incubator-mxnet-test.  The links could be included
in the report as well which might help to generate the numbers next time.
5 - You mention new mentors were added, but not why.  If the board asks, it
will be a follow up task.

Mike

On Mon, Oct 1, 2018 at 8:33 PM Haibin Lin  wrote:

> Hi MXNet community,
>
> The podling report for MXNet is due on October 3rd. The report covers
> MXNet's progress on community development and project development (the
> previous one can be found here  >).
> You can search "MXNet" at https://wiki.apache.org/incubator/October2018
> for
> MXNet's draft report for October. Please help review and contribute to the
> report before it's due.
>
> If you have any suggestions on improving the report, please let me know and
> I'm happy to update the report based on the feedback. Thanks!
>
> Best regards,
> Haibin
>