You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mxnet.apache.org by "Lausen, Leonard" <la...@amazon.com.INVALID> on 2020/05/26 16:58:54 UTC
[Lazy consensus] Removal of all repository.apache.org mxnet artifacts
(and their mirrored maven central counterparts)
On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> I see the following two potential remedies:
>
> 1) Ask the Infra team to delete all MXNet releases on repository.apache.org
>
> 2) Ask the Infra team to delete all MXNet GPU releases on
> repository.apache.org and provide replacement releases without libgfortran.so
> and other potentially Category-X files (I found libmkl_ml.so in one of the
> JARs..)
>
> If no-one steps up to do 2) or no-one suggests a better option, I recommend we
> go for option 1). Let's start discussing the options. Once discussion has
> settled, I'll initiate a lazy consensus or vote session.
As the discussion appears to have settled and there appears to be no progress on
providing replacement JARs without Category-X files for old releases, I would
like to start 72 hour lazy consensus on "Ask the Infra team to delete all MXNet
releases on repository.apache.org".
Best regards
Leonard
Re: [Lazy consensus] Removal of all repository.apache.org mxnet
artifacts (and their mirrored maven central counterparts)
Posted by Carin Meier <ca...@gmail.com>.
Zach,
If you are willing and able to do that on behalf of Amazon, that would be
great.
-Carin
On Fri, May 29, 2020 at 8:35 PM Zach Kimberg <za...@gmail.com>
wrote:
> If we replace the official CPU build, won't there still be new dependencies
> so it is not even guaranteed to work depending on whether the user has the
> dependencies (e.g. libgfortran) installed? I think there is also a
> performance degradation if we remove mkl.
>
> But, we could still have a third-party build. I can try to redo the builds
> and release it on behalf of Amazon. Those builds can contain the full
> dependencies and supported environments (CPU, GPU, OSX) and are not
> restricted to Apache's license policies. Users will only have to update
> their dependency group IDs and they will get the same functionality as they
> have now.
>
> As Apache, we will only officially support JVM by building from source.
> Then, we just mention where to find the Amazon convenience builds while
> clarifying that they are not official Apache builds.
>
> On Fri, May 29, 2020 at 10:44 AM Carin Meier <ca...@gmail.com> 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
> <lausen@amazon.com.invalid
> > >
> > 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 <ca...@gmail.com>
> > > 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)
Posted by Zach Kimberg <za...@gmail.com>.
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 <ca...@gmail.com> 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 <lausen@amazon.com.invalid
> >
> 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 <ca...@gmail.com>
> > 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)
Posted by Carin Meier <ca...@gmail.com>.
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 <la...@amazon.com.invalid>
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 <ca...@gmail.com>
> 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)
Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.
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 <ca...@gmail.com> 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)
Posted by Carin Meier <ca...@gmail.com>.
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 <ca...@gmail.com> 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 <la...@amazon.com.invalid>
> 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 <ca...@gmail.com> 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
>> <lausen@amazon.com.invalid
>> > > 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.
>> > > > >
>> > > > > Instead, we should figure out how other projects are handling
>> retired
>> > > or
>> > > > > revoked packages on the various distributed platforms. One
>> example how
>> > > to
>> > > > > approach the situation could be to 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. Another way could be to talk to the publishing
>> platforms and
>> > > > > check if there's a way to replace a package with a notice so when
>> a
>> > > > > dependency management resolves it, it won't just say "not found"
>> but
>> > > > > provide meaningful information. Simply expecting that users will
>> visit
>> > > > the
>> > > > > website and figure it out is not sufficient and to me that user
>> > > > experience
>> > > > > journey has to be addressed before we purge the releases.
>> > > > >
>> > > > > Best regards,
>> > > > > Marco
>> > > > >
>> > > > > On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard
>> > > > <la...@amazon.com.invalid>
>> > > > > wrote:
>> > > > >
>> > > > > > @Carin I created
>> > > https://github.com/apache/incubator-mxnet/pull/18410
>> > > > to
>> > > > > > update
>> > > > > > the documentation.
>> > > > > >
>> > > > > > @Marco The replacement is to build from source. But I'm afraid
>> that
>> > > > there's
>> > > > > > nothing to -1 here, as the existing convenience binaries are in
>> > > > violation
>> > > > > > of ASF
>> > > > > > policy and the ASF board has requested their removal. These
>> binaries
>> > > > only
>> > > > > > exists
>> > > > > > because the PPMC has previously failed to follow the ASF release
>> > > > policies
>> > > > > > for
>> > > > > > convenience binaries (the policies were only followed and
>> discussed
>> > > for
>> > > > > > source
>> > > > > > releases).
>> > > > > >
>> > > > > > If you have a different proposal to the ones discussed during
>> the
>> > > last
>> > > > 14
>> > > > > > days,
>> > > > > > please present it. If you would like to volunteer re-doing all
>> the
>> > > old
>> > > > > > convenience releases in an ASF compliant manner, that would
>> also be
>> > > > great.
>> > > > > > Please clarify this if your "-1" is intended to start a
>> procedural
>> > > vote
>> > > > > > according to [1] in which the majority of votes determines the
>> > > > outcome. In
>> > > > > > that
>> > > > > > case I suggest to change the email title to begin with [VOTE].
>> > > > Otherwise
>> > > > > > I'll
>> > > > > > assume the lazy consensus still remains.
>> > > > > >
>> > > > > > [1]: https://www.apache.org/foundation/voting.html
>> > > > > >
>> > > > > > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
>> > > > > >
>> > > > > > > Do we offer any replacement for those deletions or will be
>> break
>> > > > stuff
>> > > > > > > then?
>> > > > > > >
>> > > > > > > If we break anything, I'd -1 until we found a way moving
>> forward to
>> > > > > > ensure
>> > > > > > > uninterrupted service.
>> > > > > > >
>> > > > > > > On Tue, May 26, 2020 at 7:51 PM Carin Meier <
>> carinmeier@gmail.com>
>> > > > > > wrote:
>> > > > > > > > Does anyone have any bandwidth to update installation
>> > > > documentation on
>> > > > > > the
>> > > > > > > > website, so it doesn't refer them to install it from maven?
>> > > > > > > >
>> > > > > > > > Here are the links to the gpu instructions for Scala, Java,
>> and
>> > > > > > Clojure.
>> > > > > > > > The cpu ones will also need to be updated if also removed.
>> > > > > > > >
>> > > > > > > >
>> > >
>> https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
>> ;
>> > > > ;
>> > > > > > ;
>> > >
>> https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
>> ;
>> > > > ;
>> > > > > > ;
>> > >
>> https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&
>> ;
>> > > > ;
>> > > > > > ;
>> > > > > > > > Thanks,
>> > > > > > > > Carin
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
>> > > > > > <lausen@amazon.com.invalid
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
>> > > > > > > > > > I see the following two potential remedies:
>> > > > > > > > > >
>> > > > > > > > > > 1) Ask the Infra team to delete all MXNet releases on
>> > > > > > > > > repository.apache.org
>> > > > > > > > > > 2) Ask the Infra team to delete all MXNet GPU releases
>> on
>> > > > > > > > > > repository.apache.org and provide replacement releases
>> > > without
>> > > > > > > > > libgfortran.so
>> > > > > > > > > > and other potentially Category-X files (I found
>> libmkl_ml.so
>> > > in
>> > > > > > one of
>> > > > > > > > > the
>> > > > > > > > > > JARs..)
>> > > > > > > > > >
>> > > > > > > > > > If no-one steps up to do 2) or no-one suggests a better
>> > > > option, I
>> > > > > > > > > recommend we
>> > > > > > > > > > go for option 1). Let's start discussing the options.
>> Once
>> > > > > > discussion
>> > > > > > > > has
>> > > > > > > > > > settled, I'll initiate a lazy consensus or vote session.
>> > > > > > > > >
>> > > > > > > > > As the discussion appears to have settled and there
>> appears to
>> > > > be no
>> > > > > > > > > progress on
>> > > > > > > > > providing replacement JARs without Category-X files for
>> old
>> > > > > > releases, I
>> > > > > > > > > would
>> > > > > > > > > like to start 72 hour lazy consensus on "Ask the Infra
>> team to
>> > > > > > delete all
>> > > > > > > > > MXNet
>> > > > > > > > > releases on repository.apache.org".
>> > > > > > > > >
>> > > > > > > > > Best regards
>> > > > > > > > > Leonard
>> > > > > > > > >
>>
>
Re: [Lazy consensus] Removal of all repository.apache.org mxnet
artifacts (and their mirrored maven central counterparts)
Posted by Carin Meier <ca...@gmail.com>.
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 <la...@amazon.com.invalid>
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 <ca...@gmail.com> 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
> <lausen@amazon.com.invalid
> > > 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.
> > > > >
> > > > > Instead, we should figure out how other projects are handling
> retired
> > > or
> > > > > revoked packages on the various distributed platforms. One example
> how
> > > to
> > > > > approach the situation could be to 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. Another way could be to talk to the publishing
> platforms and
> > > > > check if there's a way to replace a package with a notice so when a
> > > > > dependency management resolves it, it won't just say "not found"
> but
> > > > > provide meaningful information. Simply expecting that users will
> visit
> > > > the
> > > > > website and figure it out is not sufficient and to me that user
> > > > experience
> > > > > journey has to be addressed before we purge the releases.
> > > > >
> > > > > Best regards,
> > > > > Marco
> > > > >
> > > > > On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard
> > > > <la...@amazon.com.invalid>
> > > > > wrote:
> > > > >
> > > > > > @Carin I created
> > > https://github.com/apache/incubator-mxnet/pull/18410
> > > > to
> > > > > > update
> > > > > > the documentation.
> > > > > >
> > > > > > @Marco The replacement is to build from source. But I'm afraid
> that
> > > > there's
> > > > > > nothing to -1 here, as the existing convenience binaries are in
> > > > violation
> > > > > > of ASF
> > > > > > policy and the ASF board has requested their removal. These
> binaries
> > > > only
> > > > > > exists
> > > > > > because the PPMC has previously failed to follow the ASF release
> > > > policies
> > > > > > for
> > > > > > convenience binaries (the policies were only followed and
> discussed
> > > for
> > > > > > source
> > > > > > releases).
> > > > > >
> > > > > > If you have a different proposal to the ones discussed during the
> > > last
> > > > 14
> > > > > > days,
> > > > > > please present it. If you would like to volunteer re-doing all
> the
> > > old
> > > > > > convenience releases in an ASF compliant manner, that would also
> be
> > > > great.
> > > > > > Please clarify this if your "-1" is intended to start a
> procedural
> > > vote
> > > > > > according to [1] in which the majority of votes determines the
> > > > outcome. In
> > > > > > that
> > > > > > case I suggest to change the email title to begin with [VOTE].
> > > > Otherwise
> > > > > > I'll
> > > > > > assume the lazy consensus still remains.
> > > > > >
> > > > > > [1]: https://www.apache.org/foundation/voting.html
> > > > > >
> > > > > > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
> > > > > >
> > > > > > > Do we offer any replacement for those deletions or will be
> break
> > > > stuff
> > > > > > > then?
> > > > > > >
> > > > > > > If we break anything, I'd -1 until we found a way moving
> forward to
> > > > > > ensure
> > > > > > > uninterrupted service.
> > > > > > >
> > > > > > > On Tue, May 26, 2020 at 7:51 PM Carin Meier <
> carinmeier@gmail.com>
> > > > > > wrote:
> > > > > > > > Does anyone have any bandwidth to update installation
> > > > documentation on
> > > > > > the
> > > > > > > > website, so it doesn't refer them to install it from maven?
> > > > > > > >
> > > > > > > > Here are the links to the gpu instructions for Scala, Java,
> and
> > > > > > Clojure.
> > > > > > > > The cpu ones will also need to be updated if also removed.
> > > > > > > >
> > > > > > > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
> ;
> > > > ;
> > > > > > ;
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
> ;
> > > > ;
> > > > > > ;
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&
> ;
> > > > ;
> > > > > > ;
> > > > > > > > Thanks,
> > > > > > > > Carin
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
> > > > > > <lausen@amazon.com.invalid
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > > > > > > > I see the following two potential remedies:
> > > > > > > > > >
> > > > > > > > > > 1) Ask the Infra team to delete all MXNet releases on
> > > > > > > > > repository.apache.org
> > > > > > > > > > 2) Ask the Infra team to delete all MXNet GPU releases on
> > > > > > > > > > repository.apache.org and provide replacement releases
> > > without
> > > > > > > > > libgfortran.so
> > > > > > > > > > and other potentially Category-X files (I found
> libmkl_ml.so
> > > in
> > > > > > one of
> > > > > > > > > the
> > > > > > > > > > JARs..)
> > > > > > > > > >
> > > > > > > > > > If no-one steps up to do 2) or no-one suggests a better
> > > > option, I
> > > > > > > > > recommend we
> > > > > > > > > > go for option 1). Let's start discussing the options.
> Once
> > > > > > discussion
> > > > > > > > has
> > > > > > > > > > settled, I'll initiate a lazy consensus or vote session.
> > > > > > > > >
> > > > > > > > > As the discussion appears to have settled and there
> appears to
> > > > be no
> > > > > > > > > progress on
> > > > > > > > > providing replacement JARs without Category-X files for old
> > > > > > releases, I
> > > > > > > > > would
> > > > > > > > > like to start 72 hour lazy consensus on "Ask the Infra
> team to
> > > > > > delete all
> > > > > > > > > MXNet
> > > > > > > > > releases on repository.apache.org".
> > > > > > > > >
> > > > > > > > > Best regards
> > > > > > > > > Leonard
> > > > > > > > >
>
Re: [Lazy consensus] Removal of all repository.apache.org mxnet
artifacts (and their mirrored maven central counterparts)
Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.
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 <ca...@gmail.com> 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 <lausen@amazon.com.invalid
> > 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.
> > > >
> > > > Instead, we should figure out how other projects are handling retired
> > or
> > > > revoked packages on the various distributed platforms. One example how
> > to
> > > > approach the situation could be to 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. Another way could be to talk to the publishing platforms and
> > > > check if there's a way to replace a package with a notice so when a
> > > > dependency management resolves it, it won't just say "not found" but
> > > > provide meaningful information. Simply expecting that users will visit
> > > the
> > > > website and figure it out is not sufficient and to me that user
> > > experience
> > > > journey has to be addressed before we purge the releases.
> > > >
> > > > Best regards,
> > > > Marco
> > > >
> > > > On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard
> > > <la...@amazon.com.invalid>
> > > > wrote:
> > > >
> > > > > @Carin I created
> > https://github.com/apache/incubator-mxnet/pull/18410
> > > to
> > > > > update
> > > > > the documentation.
> > > > >
> > > > > @Marco The replacement is to build from source. But I'm afraid that
> > > there's
> > > > > nothing to -1 here, as the existing convenience binaries are in
> > > violation
> > > > > of ASF
> > > > > policy and the ASF board has requested their removal. These binaries
> > > only
> > > > > exists
> > > > > because the PPMC has previously failed to follow the ASF release
> > > policies
> > > > > for
> > > > > convenience binaries (the policies were only followed and discussed
> > for
> > > > > source
> > > > > releases).
> > > > >
> > > > > If you have a different proposal to the ones discussed during the
> > last
> > > 14
> > > > > days,
> > > > > please present it. If you would like to volunteer re-doing all the
> > old
> > > > > convenience releases in an ASF compliant manner, that would also be
> > > great.
> > > > > Please clarify this if your "-1" is intended to start a procedural
> > vote
> > > > > according to [1] in which the majority of votes determines the
> > > outcome. In
> > > > > that
> > > > > case I suggest to change the email title to begin with [VOTE].
> > > Otherwise
> > > > > I'll
> > > > > assume the lazy consensus still remains.
> > > > >
> > > > > [1]: https://www.apache.org/foundation/voting.html
> > > > >
> > > > > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
> > > > >
> > > > > > Do we offer any replacement for those deletions or will be break
> > > stuff
> > > > > > then?
> > > > > >
> > > > > > If we break anything, I'd -1 until we found a way moving forward to
> > > > > ensure
> > > > > > uninterrupted service.
> > > > > >
> > > > > > On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com>
> > > > > wrote:
> > > > > > > Does anyone have any bandwidth to update installation
> > > documentation on
> > > > > the
> > > > > > > website, so it doesn't refer them to install it from maven?
> > > > > > >
> > > > > > > Here are the links to the gpu instructions for Scala, Java, and
> > > > > Clojure.
> > > > > > > The cpu ones will also need to be updated if also removed.
> > > > > > >
> > > > > > >
> > https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&;
> > > ;
> > > > > ;
> > https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&;
> > > ;
> > > > > ;
> > https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&;
> > > ;
> > > > > ;
> > > > > > > Thanks,
> > > > > > > Carin
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
> > > > > <lausen@amazon.com.invalid
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > > > > > > I see the following two potential remedies:
> > > > > > > > >
> > > > > > > > > 1) Ask the Infra team to delete all MXNet releases on
> > > > > > > > repository.apache.org
> > > > > > > > > 2) Ask the Infra team to delete all MXNet GPU releases on
> > > > > > > > > repository.apache.org and provide replacement releases
> > without
> > > > > > > > libgfortran.so
> > > > > > > > > and other potentially Category-X files (I found libmkl_ml.so
> > in
> > > > > one of
> > > > > > > > the
> > > > > > > > > JARs..)
> > > > > > > > >
> > > > > > > > > If no-one steps up to do 2) or no-one suggests a better
> > > option, I
> > > > > > > > recommend we
> > > > > > > > > go for option 1). Let's start discussing the options. Once
> > > > > discussion
> > > > > > > has
> > > > > > > > > settled, I'll initiate a lazy consensus or vote session.
> > > > > > > >
> > > > > > > > As the discussion appears to have settled and there appears to
> > > be no
> > > > > > > > progress on
> > > > > > > > providing replacement JARs without Category-X files for old
> > > > > releases, I
> > > > > > > > would
> > > > > > > > like to start 72 hour lazy consensus on "Ask the Infra team to
> > > > > delete all
> > > > > > > > MXNet
> > > > > > > > releases on repository.apache.org".
> > > > > > > >
> > > > > > > > Best regards
> > > > > > > > Leonard
> > > > > > > >
Re: [Lazy consensus] Removal of all repository.apache.org mxnet
artifacts (and their mirrored maven central counterparts)
Posted by Marco de Abreu <ma...@gmail.com>.
Thanks for your input Carin.
In that case, I'll take back my -1 and feel free to proceed.
-Marco
Carin Meier <ca...@gmail.com> 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 <lausen@amazon.com.invalid
> >
> 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.
> > >
> > > Instead, we should figure out how other projects are handling retired
> or
> > > revoked packages on the various distributed platforms. One example how
> to
> > > approach the situation could be to 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. Another way could be to talk to the publishing platforms and
> > > check if there's a way to replace a package with a notice so when a
> > > dependency management resolves it, it won't just say "not found" but
> > > provide meaningful information. Simply expecting that users will visit
> > the
> > > website and figure it out is not sufficient and to me that user
> > experience
> > > journey has to be addressed before we purge the releases.
> > >
> > > Best regards,
> > > Marco
> > >
> > > On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard
> > <la...@amazon.com.invalid>
> > > wrote:
> > >
> > > > @Carin I created
> https://github.com/apache/incubator-mxnet/pull/18410
> > to
> > > > update
> > > > the documentation.
> > > >
> > > > @Marco The replacement is to build from source. But I'm afraid that
> > there's
> > > > nothing to -1 here, as the existing convenience binaries are in
> > violation
> > > > of ASF
> > > > policy and the ASF board has requested their removal. These binaries
> > only
> > > > exists
> > > > because the PPMC has previously failed to follow the ASF release
> > policies
> > > > for
> > > > convenience binaries (the policies were only followed and discussed
> for
> > > > source
> > > > releases).
> > > >
> > > > If you have a different proposal to the ones discussed during the
> last
> > 14
> > > > days,
> > > > please present it. If you would like to volunteer re-doing all the
> old
> > > > convenience releases in an ASF compliant manner, that would also be
> > great.
> > > >
> > > > Please clarify this if your "-1" is intended to start a procedural
> vote
> > > > according to [1] in which the majority of votes determines the
> > outcome. In
> > > > that
> > > > case I suggest to change the email title to begin with [VOTE].
> > Otherwise
> > > > I'll
> > > > assume the lazy consensus still remains.
> > > >
> > > > [1]: https://www.apache.org/foundation/voting.html
> > > >
> > > > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
> > > >
> > > > > Do we offer any replacement for those deletions or will be break
> > stuff
> > > > > then?
> > > > >
> > > > > If we break anything, I'd -1 until we found a way moving forward to
> > > > ensure
> > > > > uninterrupted service.
> > > > >
> > > > > On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com>
> > > > wrote:
> > > > > > Does anyone have any bandwidth to update installation
> > documentation on
> > > > the
> > > > > > website, so it doesn't refer them to install it from maven?
> > > > > >
> > > > > > Here are the links to the gpu instructions for Scala, Java, and
> > > > Clojure.
> > > > > > The cpu ones will also need to be updated if also removed.
> > > > > >
> > > > > >
> > > >
> >
> https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
> > ;
> > > > ;
> > > > > >
> > > >
> >
> https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
> > ;
> > > > ;
> > > > > >
> > > >
> >
> https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&
> > ;
> > > > ;
> > > > > > Thanks,
> > > > > > Carin
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
> > > > <lausen@amazon.com.invalid
> > > > > > wrote:
> > > > > >
> > > > > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > > > > > I see the following two potential remedies:
> > > > > > > >
> > > > > > > > 1) Ask the Infra team to delete all MXNet releases on
> > > > > > > repository.apache.org
> > > > > > > > 2) Ask the Infra team to delete all MXNet GPU releases on
> > > > > > > > repository.apache.org and provide replacement releases
> without
> > > > > > > libgfortran.so
> > > > > > > > and other potentially Category-X files (I found libmkl_ml.so
> in
> > > > one of
> > > > > > > the
> > > > > > > > JARs..)
> > > > > > > >
> > > > > > > > If no-one steps up to do 2) or no-one suggests a better
> > option, I
> > > > > > > recommend we
> > > > > > > > go for option 1). Let's start discussing the options. Once
> > > > discussion
> > > > > > has
> > > > > > > > settled, I'll initiate a lazy consensus or vote session.
> > > > > > >
> > > > > > > As the discussion appears to have settled and there appears to
> > be no
> > > > > > > progress on
> > > > > > > providing replacement JARs without Category-X files for old
> > > > releases, I
> > > > > > > would
> > > > > > > like to start 72 hour lazy consensus on "Ask the Infra team to
> > > > delete all
> > > > > > > MXNet
> > > > > > > releases on repository.apache.org".
> > > > > > >
> > > > > > > Best regards
> > > > > > > Leonard
> > > > > > >
> >
>
Re: [Lazy consensus] Removal of all repository.apache.org mxnet
artifacts (and their mirrored maven central counterparts)
Posted by Carin Meier <ca...@gmail.com>.
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 <la...@amazon.com.invalid>
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.
> >
> > Instead, we should figure out how other projects are handling retired or
> > revoked packages on the various distributed platforms. One example how to
> > approach the situation could be to 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. Another way could be to talk to the publishing platforms and
> > check if there's a way to replace a package with a notice so when a
> > dependency management resolves it, it won't just say "not found" but
> > provide meaningful information. Simply expecting that users will visit
> the
> > website and figure it out is not sufficient and to me that user
> experience
> > journey has to be addressed before we purge the releases.
> >
> > Best regards,
> > Marco
> >
> > On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard
> <la...@amazon.com.invalid>
> > wrote:
> >
> > > @Carin I created https://github.com/apache/incubator-mxnet/pull/18410
> to
> > > update
> > > the documentation.
> > >
> > > @Marco The replacement is to build from source. But I'm afraid that
> there's
> > > nothing to -1 here, as the existing convenience binaries are in
> violation
> > > of ASF
> > > policy and the ASF board has requested their removal. These binaries
> only
> > > exists
> > > because the PPMC has previously failed to follow the ASF release
> policies
> > > for
> > > convenience binaries (the policies were only followed and discussed for
> > > source
> > > releases).
> > >
> > > If you have a different proposal to the ones discussed during the last
> 14
> > > days,
> > > please present it. If you would like to volunteer re-doing all the old
> > > convenience releases in an ASF compliant manner, that would also be
> great.
> > >
> > > Please clarify this if your "-1" is intended to start a procedural vote
> > > according to [1] in which the majority of votes determines the
> outcome. In
> > > that
> > > case I suggest to change the email title to begin with [VOTE].
> Otherwise
> > > I'll
> > > assume the lazy consensus still remains.
> > >
> > > [1]: https://www.apache.org/foundation/voting.html
> > >
> > > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
> > >
> > > > Do we offer any replacement for those deletions or will be break
> stuff
> > > > then?
> > > >
> > > > If we break anything, I'd -1 until we found a way moving forward to
> > > ensure
> > > > uninterrupted service.
> > > >
> > > > On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com>
> > > wrote:
> > > > > Does anyone have any bandwidth to update installation
> documentation on
> > > the
> > > > > website, so it doesn't refer them to install it from maven?
> > > > >
> > > > > Here are the links to the gpu instructions for Scala, Java, and
> > > Clojure.
> > > > > The cpu ones will also need to be updated if also removed.
> > > > >
> > > > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
> ;
> > > ;
> > > > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
> ;
> > > ;
> > > > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&
> ;
> > > ;
> > > > > Thanks,
> > > > > Carin
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
> > > <lausen@amazon.com.invalid
> > > > > wrote:
> > > > >
> > > > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > > > > I see the following two potential remedies:
> > > > > > >
> > > > > > > 1) Ask the Infra team to delete all MXNet releases on
> > > > > > repository.apache.org
> > > > > > > 2) Ask the Infra team to delete all MXNet GPU releases on
> > > > > > > repository.apache.org and provide replacement releases without
> > > > > > libgfortran.so
> > > > > > > and other potentially Category-X files (I found libmkl_ml.so in
> > > one of
> > > > > > the
> > > > > > > JARs..)
> > > > > > >
> > > > > > > If no-one steps up to do 2) or no-one suggests a better
> option, I
> > > > > > recommend we
> > > > > > > go for option 1). Let's start discussing the options. Once
> > > discussion
> > > > > has
> > > > > > > settled, I'll initiate a lazy consensus or vote session.
> > > > > >
> > > > > > As the discussion appears to have settled and there appears to
> be no
> > > > > > progress on
> > > > > > providing replacement JARs without Category-X files for old
> > > releases, I
> > > > > > would
> > > > > > like to start 72 hour lazy consensus on "Ask the Infra team to
> > > delete all
> > > > > > MXNet
> > > > > > releases on repository.apache.org".
> > > > > >
> > > > > > Best regards
> > > > > > Leonard
> > > > > >
>
Re: [Lazy consensus] Removal of all repository.apache.org mxnet
artifacts (and their mirrored maven central counterparts)
Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.
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.
>
> Instead, we should figure out how other projects are handling retired or
> revoked packages on the various distributed platforms. One example how to
> approach the situation could be to 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. Another way could be to talk to the publishing platforms and
> check if there's a way to replace a package with a notice so when a
> dependency management resolves it, it won't just say "not found" but
> provide meaningful information. Simply expecting that users will visit the
> website and figure it out is not sufficient and to me that user experience
> journey has to be addressed before we purge the releases.
>
> Best regards,
> Marco
>
> On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard <la...@amazon.com.invalid>
> wrote:
>
> > @Carin I created https://github.com/apache/incubator-mxnet/pull/18410 to
> > update
> > the documentation.
> >
> > @Marco The replacement is to build from source. But I'm afraid that there's
> > nothing to -1 here, as the existing convenience binaries are in violation
> > of ASF
> > policy and the ASF board has requested their removal. These binaries only
> > exists
> > because the PPMC has previously failed to follow the ASF release policies
> > for
> > convenience binaries (the policies were only followed and discussed for
> > source
> > releases).
> >
> > If you have a different proposal to the ones discussed during the last 14
> > days,
> > please present it. If you would like to volunteer re-doing all the old
> > convenience releases in an ASF compliant manner, that would also be great.
> >
> > Please clarify this if your "-1" is intended to start a procedural vote
> > according to [1] in which the majority of votes determines the outcome. In
> > that
> > case I suggest to change the email title to begin with [VOTE]. Otherwise
> > I'll
> > assume the lazy consensus still remains.
> >
> > [1]: https://www.apache.org/foundation/voting.html
> >
> > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
> >
> > > Do we offer any replacement for those deletions or will be break stuff
> > > then?
> > >
> > > If we break anything, I'd -1 until we found a way moving forward to
> > ensure
> > > uninterrupted service.
> > >
> > > On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com>
> > wrote:
> > > > Does anyone have any bandwidth to update installation documentation on
> > the
> > > > website, so it doesn't refer them to install it from maven?
> > > >
> > > > Here are the links to the gpu instructions for Scala, Java, and
> > Clojure.
> > > > The cpu ones will also need to be updated if also removed.
> > > >
> > > >
> > https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&;
> > ;
> > > >
> > https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&;
> > ;
> > > >
> > https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&;
> > ;
> > > > Thanks,
> > > > Carin
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
> > <lausen@amazon.com.invalid
> > > > wrote:
> > > >
> > > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > > > I see the following two potential remedies:
> > > > > >
> > > > > > 1) Ask the Infra team to delete all MXNet releases on
> > > > > repository.apache.org
> > > > > > 2) Ask the Infra team to delete all MXNet GPU releases on
> > > > > > repository.apache.org and provide replacement releases without
> > > > > libgfortran.so
> > > > > > and other potentially Category-X files (I found libmkl_ml.so in
> > one of
> > > > > the
> > > > > > JARs..)
> > > > > >
> > > > > > If no-one steps up to do 2) or no-one suggests a better option, I
> > > > > recommend we
> > > > > > go for option 1). Let's start discussing the options. Once
> > discussion
> > > > has
> > > > > > settled, I'll initiate a lazy consensus or vote session.
> > > > >
> > > > > As the discussion appears to have settled and there appears to be no
> > > > > progress on
> > > > > providing replacement JARs without Category-X files for old
> > releases, I
> > > > > would
> > > > > like to start 72 hour lazy consensus on "Ask the Infra team to
> > delete all
> > > > > MXNet
> > > > > releases on repository.apache.org".
> > > > >
> > > > > Best regards
> > > > > Leonard
> > > > >
Re: [Lazy consensus] Removal of all repository.apache.org mxnet
artifacts (and their mirrored maven central counterparts)
Posted by Marco de Abreu <ma...@gmail.com>.
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.
Instead, we should figure out how other projects are handling retired or
revoked packages on the various distributed platforms. One example how to
approach the situation could be to 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. Another way could be to talk to the publishing platforms and
check if there's a way to replace a package with a notice so when a
dependency management resolves it, it won't just say "not found" but
provide meaningful information. Simply expecting that users will visit the
website and figure it out is not sufficient and to me that user experience
journey has to be addressed before we purge the releases.
Best regards,
Marco
On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard <la...@amazon.com.invalid>
wrote:
> @Carin I created https://github.com/apache/incubator-mxnet/pull/18410 to
> update
> the documentation.
>
> @Marco The replacement is to build from source. But I'm afraid that there's
> nothing to -1 here, as the existing convenience binaries are in violation
> of ASF
> policy and the ASF board has requested their removal. These binaries only
> exists
> because the PPMC has previously failed to follow the ASF release policies
> for
> convenience binaries (the policies were only followed and discussed for
> source
> releases).
>
> If you have a different proposal to the ones discussed during the last 14
> days,
> please present it. If you would like to volunteer re-doing all the old
> convenience releases in an ASF compliant manner, that would also be great.
>
> Please clarify this if your "-1" is intended to start a procedural vote
> according to [1] in which the majority of votes determines the outcome. In
> that
> case I suggest to change the email title to begin with [VOTE]. Otherwise
> I'll
> assume the lazy consensus still remains.
>
> [1]: https://www.apache.org/foundation/voting.html
>
> On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
>
> > Do we offer any replacement for those deletions or will be break stuff
> > then?
> >
> > If we break anything, I'd -1 until we found a way moving forward to
> ensure
> > uninterrupted service.
> >
> > On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com>
> wrote:
> >
> > > Does anyone have any bandwidth to update installation documentation on
> the
> > > website, so it doesn't refer them to install it from maven?
> > >
> > > Here are the links to the gpu instructions for Scala, Java, and
> Clojure.
> > > The cpu ones will also need to be updated if also removed.
> > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
> ;
> > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
> ;
> > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&
> ;
> > >
> > > Thanks,
> > > Carin
> > >
> > >
> > >
> > >
> > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
> <lausen@amazon.com.invalid
> > > wrote:
> > >
> > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > > I see the following two potential remedies:
> > > > >
> > > > > 1) Ask the Infra team to delete all MXNet releases on
> > > > repository.apache.org
> > > > > 2) Ask the Infra team to delete all MXNet GPU releases on
> > > > > repository.apache.org and provide replacement releases without
> > > > libgfortran.so
> > > > > and other potentially Category-X files (I found libmkl_ml.so in
> one of
> > > > the
> > > > > JARs..)
> > > > >
> > > > > If no-one steps up to do 2) or no-one suggests a better option, I
> > > > recommend we
> > > > > go for option 1). Let's start discussing the options. Once
> discussion
> > > has
> > > > > settled, I'll initiate a lazy consensus or vote session.
> > > >
> > > > As the discussion appears to have settled and there appears to be no
> > > > progress on
> > > > providing replacement JARs without Category-X files for old
> releases, I
> > > > would
> > > > like to start 72 hour lazy consensus on "Ask the Infra team to
> delete all
> > > > MXNet
> > > > releases on repository.apache.org".
> > > >
> > > > Best regards
> > > > Leonard
> > > >
>
Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts
(and their mirrored maven central counterparts)
Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.
@Carin I created https://github.com/apache/incubator-mxnet/pull/18410 to update
the documentation.
@Marco The replacement is to build from source. But I'm afraid that there's
nothing to -1 here, as the existing convenience binaries are in violation of ASF
policy and the ASF board has requested their removal. These binaries only exists
because the PPMC has previously failed to follow the ASF release policies for
convenience binaries (the policies were only followed and discussed for source
releases).
If you have a different proposal to the ones discussed during the last 14 days,
please present it. If you would like to volunteer re-doing all the old
convenience releases in an ASF compliant manner, that would also be great.
Please clarify this if your "-1" is intended to start a procedural vote
according to [1] in which the majority of votes determines the outcome. In that
case I suggest to change the email title to begin with [VOTE]. Otherwise I'll
assume the lazy consensus still remains.
[1]: https://www.apache.org/foundation/voting.html
On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
> Do we offer any replacement for those deletions or will be break stuff
> then?
>
> If we break anything, I'd -1 until we found a way moving forward to ensure
> uninterrupted service.
>
> On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com> wrote:
>
> > Does anyone have any bandwidth to update installation documentation on the
> > website, so it doesn't refer them to install it from maven?
> >
> > Here are the links to the gpu instructions for Scala, Java, and Clojure.
> > The cpu ones will also need to be updated if also removed.
> >
> > https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&;
> >
> > https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&;
> >
> > https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&;
> >
> > Thanks,
> > Carin
> >
> >
> >
> >
> > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard <lausen@amazon.com.invalid
> > wrote:
> >
> > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > I see the following two potential remedies:
> > > >
> > > > 1) Ask the Infra team to delete all MXNet releases on
> > > repository.apache.org
> > > > 2) Ask the Infra team to delete all MXNet GPU releases on
> > > > repository.apache.org and provide replacement releases without
> > > libgfortran.so
> > > > and other potentially Category-X files (I found libmkl_ml.so in one of
> > > the
> > > > JARs..)
> > > >
> > > > If no-one steps up to do 2) or no-one suggests a better option, I
> > > recommend we
> > > > go for option 1). Let's start discussing the options. Once discussion
> > has
> > > > settled, I'll initiate a lazy consensus or vote session.
> > >
> > > As the discussion appears to have settled and there appears to be no
> > > progress on
> > > providing replacement JARs without Category-X files for old releases, I
> > > would
> > > like to start 72 hour lazy consensus on "Ask the Infra team to delete all
> > > MXNet
> > > releases on repository.apache.org".
> > >
> > > Best regards
> > > Leonard
> > >
Re: [Lazy consensus] Removal of all repository.apache.org mxnet
artifacts (and their mirrored maven central counterparts)
Posted by Marco de Abreu <ma...@gmail.com>.
Do we offer any replacement for those deletions or will be break stuff
then?
If we break anything, I'd -1 until we found a way moving forward to ensure
uninterrupted service.
On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com> wrote:
> Does anyone have any bandwidth to update installation documentation on the
> website, so it doesn't refer them to install it from maven?
>
> Here are the links to the gpu instructions for Scala, Java, and Clojure.
> The cpu ones will also need to be updated if also removed.
>
> https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
>
> https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
>
> https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&
>
> Thanks,
> Carin
>
>
>
>
> On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard <lausen@amazon.com.invalid
> >
> wrote:
>
> > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > I see the following two potential remedies:
> > >
> > > 1) Ask the Infra team to delete all MXNet releases on
> > repository.apache.org
> > >
> > > 2) Ask the Infra team to delete all MXNet GPU releases on
> > > repository.apache.org and provide replacement releases without
> > libgfortran.so
> > > and other potentially Category-X files (I found libmkl_ml.so in one of
> > the
> > > JARs..)
> > >
> > > If no-one steps up to do 2) or no-one suggests a better option, I
> > recommend we
> > > go for option 1). Let's start discussing the options. Once discussion
> has
> > > settled, I'll initiate a lazy consensus or vote session.
> >
> > As the discussion appears to have settled and there appears to be no
> > progress on
> > providing replacement JARs without Category-X files for old releases, I
> > would
> > like to start 72 hour lazy consensus on "Ask the Infra team to delete all
> > MXNet
> > releases on repository.apache.org".
> >
> > Best regards
> > Leonard
> >
>
Re: [Lazy consensus] Removal of all repository.apache.org mxnet
artifacts (and their mirrored maven central counterparts)
Posted by Carin Meier <ca...@gmail.com>.
Does anyone have any bandwidth to update installation documentation on the
website, so it doesn't refer them to install it from maven?
Here are the links to the gpu instructions for Scala, Java, and Clojure.
The cpu ones will also need to be updated if also removed.
https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&
Thanks,
Carin
On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard <la...@amazon.com.invalid>
wrote:
> On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > I see the following two potential remedies:
> >
> > 1) Ask the Infra team to delete all MXNet releases on
> repository.apache.org
> >
> > 2) Ask the Infra team to delete all MXNet GPU releases on
> > repository.apache.org and provide replacement releases without
> libgfortran.so
> > and other potentially Category-X files (I found libmkl_ml.so in one of
> the
> > JARs..)
> >
> > If no-one steps up to do 2) or no-one suggests a better option, I
> recommend we
> > go for option 1). Let's start discussing the options. Once discussion has
> > settled, I'll initiate a lazy consensus or vote session.
>
> As the discussion appears to have settled and there appears to be no
> progress on
> providing replacement JARs without Category-X files for old releases, I
> would
> like to start 72 hour lazy consensus on "Ask the Infra team to delete all
> MXNet
> releases on repository.apache.org".
>
> Best regards
> Leonard
>