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

[Carin Meier]

Leonard,

Is this #2 Option still on the table?

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

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

- Carin

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

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

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

[Carin Meier]

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

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

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

undefined behavior in tensor.h

[Oliver Kowalke]

Hi,
code in mshadow/mshadow/tensor.h might cause UB.
Member function Shape::operator[](int idx) does not check for array
boundaries.
GCC causes a warning (error with -Werror).
How to deal with it? Is it accepted to patch 3rdpart components?
A solution is to throw an exception (costs runtime performance), another is
to disable the warning for this specific code (then the user must check it).
Oliver

Re: undefined behavior in tensor.h

[Skalicky, Sam]

Hi Oliver,

MShadow was a 3rd party component, but since its deprecation it was donated to 
the MXNet community and the source code is now only in the MXNet github repo 
(not a true 3rd party component anymore). Feel free to open a PR with a fix.

Thanks!
Sam

On 5/29/20, 9:46 AM, "Oliver Kowalke"  wrote:

CAUTION: This email originated from outside of the organization. Do not 
click links or open attachments unless you can confirm the sender and know the 
content is safe.



Hi,
code in mshadow/mshadow/tensor.h might cause UB.
Member function Shape::operator[](int idx) does not check for array
boundaries.
GCC causes a warning (error with -Werror).
How to deal with it? Is it accepted to patch 3rdpart components?
A solution is to throw an exception (costs runtime performance), another is
to disable the warning for this specific code (then the user must check it).
Oliver

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

[Lausen, Leonard]

On Fri, 2020-05-29 at 12:15 -0400, Carin Meier wrote:
> 
> Going forward - we with future releases, we can have all users build their
> own packages, just for the existing ones that are compliant on maven.
> 
> On Fri, May 29, 2020 at 12:14 PM Carin Meier  wrote:
> 
> > Leonard,
> > 
> > Is this #2 Option still on the table?
> > 
> >  2) Ask the Infra team to delete all MXNet GPU releases on
> > > repository.apache.org and provide replacement releases without
> > libgfortran.so
> > > and other potentially Category-X files (I found libmkl_ml.so in one of
> > the
> > > JARs..)
> > 
> > It seems like it would be a better solution than deleting ALL of them, if
> > the CPU ones are still valid and adhere to licensing.
> > At least, we would break fewer users.
> > 
> > - Carin

Yes, this is a valid option. Just to clarify, the existing CPU releases don't
adhere to the ASF policy. But MXNet project could create new, compliant CPU
releases and upload them to repository.apache.org. Finding a way to do this for
the existing 1.x releases would also establish a path forward to continue
creating such JARs for upcoming releases.

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

[Carin Meier]

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

- Carin

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

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

Re: Requesting slack access

[Chaitanya Bapat]

Hey Alex,

Welcome to the MXNet community!

I can see Leo and Joshua jump in to help with the issue. Hope we get to the
end of this and resolve your issue.
Let us know if you need any other help as well.

Thanks
Chai

On Thu, 28 May 2020 at 14:17, Alex Sisu  wrote:

> Hey guys,
>
> I want to get access to your slack channel with the hope of finding a
> solution for this issue:
> https://github.com/apache/incubator-mxnet/issues/18321
>
>
> Thanks,
>
> Alex
>


-- 
*Chaitanya Prakash Bapat*
*+1 (973) 953-6299*

[image: https://www.linkedin.com//in/chaibapat25]
[image: https://www.facebook.com/chaibapat]
[image:
https://twitter.com/ChaiBapchya] [image:
https://www.linkedin.com//in/chaibapat25]

Re: add me to the slack group

[Chaitanya Bapat]

Hello Bishal

I've sent you an invite to the Slack channel.

Welcome to the MXNet community!
Let us know if you need any help.

Thanks,
Chai

On Thu, 28 May 2020 at 22:33, Bishal Saha  wrote:

> The forms are usefull but slack gives much more power and helps to discuss
> projects :)
>


-- 
*Chaitanya Prakash Bapat*
*+1 (973) 953-6299*

[image: https://www.linkedin.com//in/chaibapat25]
[image: https://www.facebook.com/chaibapat]
[image:
https://twitter.com/ChaiBapchya] [image:
https://www.linkedin.com//in/chaibapat25]

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

[Zach Kimberg]

If we replace the official CPU build, won't there still be new dependencies
so it is not even guaranteed to work depending on whether the user has the
dependencies (e.g. libgfortran) installed? I think there is also a
performance degradation if we remove mkl.

But, we could still have a third-party build. I can try to redo the builds
and release it on behalf of Amazon. Those builds can contain the full
dependencies and supported environments (CPU, GPU, OSX) and are not
restricted to Apache's license policies. Users will only have to update
their dependency group IDs and they will get the same functionality as they
have now.

As Apache, we will only officially support JVM by building from source.
Then, we just mention where to find the Amazon convenience builds while
clarifying that they are not official Apache builds.

On Fri, May 29, 2020 at 10:44 AM Carin Meier  wrote:

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

Requesting Slack Access

[Bishal Saha]

I did sent an email but didn’t get any response.
Can anyone help me!