incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <ro...@shaposhnik.org>
Subject Re: Tying Dockerhub into development and release management
Date Wed, 06 Feb 2019 21:22:32 GMT
On Wed, Feb 6, 2019 at 10:12 PM Hen <bayard@apache.org> wrote:

> On Tue, Feb 5, 2019 at 6:45 AM Roman Shaposhnik <roman@shaposhnik.org>
> wrote:
>
> > On Tue, Feb 5, 2019 at 2:48 PM Dave <snoopdave@gmail.com> wrote:
> >
> > > I totally agree with you that Docker images should be built from
> official
> > > source releases, unless they are clearly marked as unofficial SNAPSHOT
> > > releases and intended for testing. I'm just repeating what I've heard
> > over
> > > and over again from various ASF members that the only official release
> is
> > > the source release; I'd don't agree with that point of view.
> > >
> > > I'm curious what "built from the official source releases". Does that
> > mean
> > > that you must create Docker images by downloading the official source
> > > release, verifying it's hash and then building image?  Or, are you
> > allowed
> > > to build your Docker images from the same SCM tag as was used to create
> > the
> > > source release?
> > >
> >
> > I think an acceptable solution could be:
> >    * make sure that your :latest tag either points to a Docker scratch
> > container
> >      or a container that simply prints Incubator disclaimer and exists
> >    * introduce a tagging scheme for nightly builds (personally I'm quite
> > fond
> >      of tagging nightly docker builds with SHAs from your git tree from
> > which
> >      you build the image)
> >    * introduce :snapshot tag that points at the latest tag from previous
> > item
> >
> > I feel that this could be passable for IPMC.
> >
> >
> I remain confused on this topic.
>

We're not talking about "official" release binaries (whatever that means at
ASF).
We're talking about snapshot binaries that need to be available for
developers.
I don't think the rest of your reasoning applies *to this* particular
discussion.


>
> The legal-discuss thread leads me to think the current state is:
>
> 1. The PPMC release some source code. They may release convenience binaries
> on the Apache distribution urls, or in Maven Central (via Infra's support),
> and those binaries must be built from the release soruce.
> 2. The PPMC should not publish software outside of Apache controlled
> locations.
> 3. Third parties may publish software based on Apache's, but they must not
> cause user confusion (i.e. respect trademarks).
> 4. The PPMC may link to the software (including binaries) published by a
> third party, but they should flag that it does not come from Apache and
> should not treat it as the default user experience.
>
> All of which means PPMCs must not use PyPI, NuGet, NPM, DockerHub, etc.
> unless Infra actively support a mechanism of doing so (which they
> definitely do for Maven).
>
> (Though I'm confused as to whether #2 is a must not, should not, or can if
> they wish to)
>
> Hen
>

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