Re: Tying Dockerhub into development and release management

On Wed, Feb 6, 2019 at 3:41 PM Justin Mclean wrote: > > Hi, > > > 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 >

Aw: Re: Tying Dockerhub into development and release management

> Gesendet: Freitag, 08. Februar 2019 um 04:58 Uhr > Von: "Dave Fisher" > An: general@incubator.apache.org > Betreff: Re: Tying Dockerhub into development and release management [...] > > On Feb 7, 2019, at 7:51 PM, Chris Lambertus wrote: [...] > >> On F

Re: Tying Dockerhub into development and release management

Sent from my iPhone > On Feb 7, 2019, at 7:51 PM, Chris Lambertus wrote: > > > >> On Feb 7, 2019, at 6:47 PM, Justin Mclean wrote: >> >> Hi, >> >>> Infra does not police what projects deploy on their dockerhub repos. Do we >>> need to? >> >> Well from a casual glance I can see several

Re: Tying Dockerhub into development and release management

> On Feb 7, 2019, at 6:47 PM, Justin Mclean wrote: > > Hi, > >> Infra does not police what projects deploy on their dockerhub repos. Do we >> need to? > > Well from a casual glance I can see several projects that seem to be putting > releases constructed from unapproved source code up

Re: Tying Dockerhub into development and release management

Hi, > Infra does not police what projects deploy on their dockerhub repos. Do we > need to? Well from a casual glance I can see several projects that seem to be putting releases constructed from unapproved source code up there. I’ve not looked in detail so may be mistaken. I guess sit depends

Re: Tying Dockerhub into development and release management

> On Feb 7, 2019, at 5:53 PM, Justin Mclean wrote: > > Hi, > >> Infra manages the u/apache dockerhub org. We provide this service with the >> express caveat that projects note that these are UNOFFICIAL releases, and >> CONVENIENCE BINARIES ONLY. > > By that I assume you mean only

Re: Tying Dockerhub into development and release management

Hi, > Infra manages the u/apache dockerhub org. We provide this service with the > express caveat that projects note that these are UNOFFICIAL releases, and > CONVENIENCE BINARIES ONLY. By that I assume you mean only connivance binaries only created from an official approved/voted on ASF

Re: Tying Dockerhub into development and release management

> On Feb 7, 2019, at 4:54 PM, Justin Mclean wrote: > > Hi, > >> I assume that "https://hub.docker.com/u/apache >> " is an Apache controlled >> location, so publishing Apache images from there is fine provided they obey >> our policies (release policy,

Re: Tying Dockerhub into development and release management

Hi, > Ignore me on this thread. I'll take my ignorance off to a special corner > and let it beat me up a bit more. The podlings are already there waiting for you :-) So what can we offer on guidance to podlings around: 1) Making official releases available on docker (or other platforms)? 2)

Re: Tying Dockerhub into development and release management

Hi, > I assume that "https://hub.docker.com/u/apache > " is an Apache controlled > location, so publishing Apache images from there is fine provided they obey > our policies (release policy, website policy etc). I believe INFA has something to do with setting

Re: Tying Dockerhub into development and release management

On Thu, Feb 7, 2019 at 4:43 PM Hen wrote: > > > On Thu, Feb 7, 2019 at 1:49 PM Justin Mclean > wrote: > >> Hi, >> >> > 2. The PPMC should not publish software outside of Apache controlled >> locations. >> >> I’m trying to find where the above has come from as I can find anything >> in the

Re: Tying Dockerhub into development and release management

On Thu, Feb 7, 2019 at 1:49 PM Justin Mclean wrote: > Hi, > > > 2. The PPMC should not publish software outside of Apache controlled > locations. > > I’m trying to find where the above has come from as I can find anything in > the release or distribution policies. [1] says “It is appropriate to

Re: Tying Dockerhub into development and release management

Hi, > 2. The PPMC should not publish software outside of Apache controlled > locations. I’m trying to find where the above has come from as I can find anything in the release or distribution policies. [1] says “It is appropriate to distribute official releases through downstream channels, but

Re: Tying Dockerhub into development and release management

Hey Justin -- any chance you can take a look at the proposed policy for *snapshot* Docker hub artifacts I proposed up-thread? Thanks, Roman. On Thu, Feb 7, 2019 at 6:13 AM Justin Mclean wrote: > Hi, > > > AFAIK everyone releasing binary convenience to dockerhub believed they > were authorized.

Re: Tying Dockerhub into development and release management

Hi, > AFAIK everyone releasing binary convenience to dockerhub believed they were > authorized. I didn't have a problem with them if they are based on actual released software, although it seem it’s now not clear that in line with policy or not, lets alone if a PPMC can release tagged

Re: Tying Dockerhub into development and release management

Hey - not everyone agrees with Justin’s and Henry’s conclusions. I don’t have time to argue every point. AFAIK everyone releasing binary convenience to dockerhub believed they were authorized. Pulsar had ONE release that was current for a short time that mistakenly kept an RC in the name. It

Re: Tying Dockerhub into development and release management

On Wed, Feb 6, 2019 at 8:34 PM Justin Mclean wrote: > HI, > > > 2. The PPMC should not publish software outside of Apache controlled > > locations. > > We have TLP / PMCs doing that already > > > 3. Third parties may publish software based on Apache's, but they must > not > > cause user

Re: Tying Dockerhub into development and release management

HI, > 2. The PPMC should not publish software outside of Apache controlled > locations. We have TLP / PMCs doing that already > 3. Third parties may publish software based on Apache's, but they must not > cause user confusion (i.e. respect trademarks). And we have this as well (see docker

Re: Tying Dockerhub into development and release management

Seems like some well established projects need some schooling from The Incubator :-) On Wed, Feb 6, 2019 at 6:41 PM Justin Mclean wrote: > Hi, > > > If projects want to make convenience binaries available for installation > > via Docker and DockerHub, then it seems like we need an official

Re: Tying Dockerhub into development and release management

Hi, > 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? A quick look shows HTTP, Maven, Tomcat,

Re: Tying Dockerhub into development and release management

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

Re: Tying Dockerhub into development and release management

On Wed, Feb 6, 2019 at 10:12 PM Hen wrote: > On Tue, Feb 5, 2019 at 6:45 AM Roman Shaposhnik > wrote: > > > On Tue, Feb 5, 2019 at 2:48 PM Dave wrote: > > > > > I totally agree with you that Docker images should be built from > official > > > source releases, unless they are clearly marked as

Re: Tying Dockerhub into development and release management

On Tue, Feb 5, 2019 at 6:45 AM Roman Shaposhnik wrote: > On Tue, Feb 5, 2019 at 2:48 PM Dave 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.

Re: Tying Dockerhub into development and release management

On Tue, Feb 5, 2019 at 2:48 PM Dave 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

Re: Tying Dockerhub into development and release management

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

Re: Tying Dockerhub into development and release management

Hi, > My understanding is that only source-code releases are official releases. > Binaries are just a convenience and not official, so I don't think you have > to worry about making images available via DockerHub, even if that is the > primary way most people install. -1 the PMC can’t release

Re: Tying Dockerhub into development and release management

My understanding is that only source-code releases are official releases. Binaries are just a convenience and not official, so I don't think you have to worry about making images available via DockerHub, even if that is the primary way most people install. Dave On Sun, Feb 3, 2019 at 1:00 PM

Re: Tying Dockerhub into development and release management

it to the repo. Get Outlook for Android<https://aka.ms/ghei36> From: lewis john mcgibbney Sent: Sunday, February 3, 2019 10:00:39 AM To: general@incubator.apache.org Cc: d...@sdap.apache.org Subject: Tying Dockerhub into development and release manageme

Re: Tying Dockerhub into development and release management

Hi, > The issue we have run into however is that the availability of Docker > images in Dockerhub appears to be in violation of Apache release policy. Is > this true for all images e.g. tagged and version controlled, hosted within > Dockerhub or is it acceptable for us to publish version

Tying Dockerhub into development and release management

Hi general@, Over at the SDAP podling we are currently involved in a bit of a situation regarding the use of Dockerhub in our development and release management. The primary mechanism for the deployment of SDAP’s NEXUS component is Docker. It is therefore necessary for us to have available Docker