mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carin Meier <carinme...@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:52:46 GMT
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