Hi, Sean.
Yes. We should keep this minimal.
BTW, for the following questions,
> But how much value does that add?
How much value do you think we have at our binary distribution in the
following link?
-
https://www.apache.org/dist/spark/spark-2.4.5/spark-2.4.5-bin-hadoop2.7.tgz
Docker image can have a similar value with the above for the users who are
using Dockerized environment.
If you are assuming the users who build from the source code or lives on
vendor distributions, both the above existing binary distribution link and
Docker image have no value.
Bests,
Dongjoon.
On Tue, Feb 11, 2020 at 8:51 AM Sean Owen <sro...@gmail.com> wrote:
> To be clear this is a convenience 'binary' for end users, not just an
> internal packaging to aid the testing framework?
>
> There's nothing wrong with providing an additional official packaging
> if we vote on it and it follows all the rules. There is an open
> question about how much value it adds vs that maintenance. I see we do
> already have some Dockerfiles, sure. Is it possible to reuse or
> repurpose these so that we don't have more to maintain? or: what is
> different from the existing Dockerfiles here? (dumb question, never
> paid much attention to them)
>
> We definitely can't release GPL bits or anything, yes. Just releasing
> a Dockerfile referring to GPL bits is a gray area - no bits are being
> redistributed, but, does it constitute a derived work where the GPL
> stuff is a non-optional dependency? Would any publishing of these
> images cause us to put a copy of third party GPL code anywhere?
>
> At the least, we should keep this minimal. One image if possible, that
> you overlay on top of your preferred OS/Java/Python image. But how
> much value does that add? I have no info either way that people want
> or don't need such a thing.
>
> On Tue, Feb 11, 2020 at 10:13 AM Erik Erlandson <eerla...@redhat.com>
> wrote:
> >
> > My takeaway from the last time we discussed this was:
> > 1) To be ASF compliant, we needed to only publish images at official
> releases
> > 2) There was some ambiguity about whether or not a container image that
> included GPL'ed packages (spark images do) might trip over the GPL "viral
> propagation" due to integrating ASL and GPL in a "binary release". The
> "air gap" GPL provision may apply - the GPL software interacts only at
> command-line boundaries.
> >
> > On Wed, Feb 5, 2020 at 1:23 PM Dongjoon Hyun <dongjoon.h...@gmail.com>
> wrote:
> >>
> >> Hi, All.
> >>
> >> From 2020, shall we have an official Docker image repository as an
> additional distribution channel?
> >>
> >> I'm considering the following images.
> >>
> >> - Public binary release (no snapshot image)
> >> - Public non-Spark base image (OS + R + Python)
> >> (This can be used in GitHub Action Jobs and Jenkins K8s
> Integration Tests to speed up jobs and to have more stabler environments)
> >>
> >> Bests,
> >> Dongjoon.
>
