mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco de Abreu <marco.g.ab...@gmail.com>
Subject Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)
Date Wed, 27 May 2020 12:54:22 GMT
Thanks for your input Carin.

In that case, I'll take back my -1 and feel free to proceed.

-Marco

Carin Meier <carinmeier@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
> > <lausen@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
> > > > > > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message