Thanks, Hen. Seems like the "Apache controlled locations" bit is important here.
If projects want to make convenience binaries available for installation via Docker and DockerHub, then it seems like we need an official Apache DockerHub repository. Do we have one of those, or are folks just publishing to personal repos? I recently made a Docker image available for the unreleased Apache Roller 6.0.0-SNAPSHOT on my personal DockerHub account, which I believe is kosher, but where should the Roller project publish the convenience binary/Docker image for the official 6.0.0 release? Thanks, Dave On Wed, Feb 6, 2019 at 4:22 PM Roman Shaposhnik <ro...@shaposhnik.org> wrote: > On Wed, Feb 6, 2019 at 10:12 PM Hen <bay...@apache.org> wrote: > > > On Tue, Feb 5, 2019 at 6:45 AM Roman Shaposhnik <ro...@shaposhnik.org> > > wrote: > > > > > On Tue, Feb 5, 2019 at 2:48 PM Dave <snoopd...@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 > > >
