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 Fri, 29 May 2020 16:15:45 GMT
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 <carinmeier@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 <lausen@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 <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