[DISCUSS] Guidelines for distribution of incubating artefacts on other platforms

Hi, Feedback welcome. If you think anything here is not in line with the ASF release and distribution policy please speak up. Currently it’s not clear to me if RCs, snapshots or nightlys would be allowed on these platforms so some changes may need to be made. If you want to add another

Re: [DISCUSS] Training (incubating) Proposal

Hi, > discussion seems to have died down. Before moving on I'd really like to > hear the opinions of the interested contributors on which direction to go. > Otherwise we might have to put it to a vote? Perhaps I biased, but I think going via the incubator is alway helpful. :-) The big question

Re: [DISCUSS] Training (incubating) Proposal

Hello everyone, discussion seems to have died down. Before moving on I'd really like to hear the opinions of the interested contributors on which direction to go. Otherwise we might have to put it to a vote? Cheers, Lars On Mon, Feb 4, 2019 at 11:52 AM Lars Francke wrote: > Dmitry, > > I

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: Draft incubator report

Hi, > If the non-approved artifact is not advertised on the download page and is > made available to the development community on request then we are good. Well I think so, but I’m sure that release policy does and infra doesn’t seem to allow it on docker hub, but perhaps they do “unofficial”

Re: Draft incubator report

Sent from my iPhone > On Feb 7, 2019, at 6:51 PM, Justin Mclean wrote: > > Hi, > > Give the response from intro on use of docker. it would seem that this is not > actually allowed. > >> Nightly builds for project-internal use clearly marked as "snapshot" or >> "prerelease" (or similar)

Re: Draft incubator report

Hi, > Give the response from intro on use of docker. it would seem that this is not > actually allowed. "response from INFRA" sorry. Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional

Re: Draft incubator report

Hi, Give the response from intro on use of docker. it would seem that this is not actually allowed. > Nightly builds for project-internal use clearly marked as "snapshot" or > "prerelease" (or similar) can be made available to project contributors. If > in doubt please ask your mentors or on

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: Draft incubator report

Hi - > On Feb 7, 2019, at 3:41 PM, Justin Mclean wrote: > > Hi, > >> I respectfully request that you edit the following to make it less alarming >> and remove any implication that the IPMC cannot handle our duties. > > I don’t read that implication there, this is quite factual all of the

Re: Draft incubator report

Hi, > I respectfully request that you edit the following to make it less alarming > and remove any implication that the IPMC cannot handle our duties. I don’t read that implication there, this is quite factual all of the project had issues with unapproved releases that had gone unnoticed. I’ll

Re: Draft incubator report

Hi Justin, Given today’s discussion regarding ShardingSphere and how pre-Apache releases came in I think we have everything available for the Mentors to deal with any issues with ECharts. I respectfully request that you edit the following to make it less alarming and remove any implication

Re: Unapproved Sharding Sphere releases

> On Feb 7, 2019, at 1:55 PM, Justin Mclean wrote: > > Hi, > >> Do we recommend that the Title be changed to add “Non-Apache release from >> prior to Incubation” or would it be sufficient for that text to be added to >> the Description? > > IMO however the PPMC want to handle it as long

Re: Unapproved Sharding Sphere releases

Hi, > Do we recommend that the Title be changed to add “Non-Apache release from > prior to Incubation” or would it be sufficient for that text to be added to > the Description? IMO however the PPMC want to handle it as long as it’s clear it’s not an Apache release and came before the

Re: Unapproved Sharding Sphere releases

> On Feb 7, 2019, at 1:44 PM, Craig Russell wrote: > >> On Feb 7, 2019, at 11:02 AM, Dave Fisher wrote: >> >>> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289 >>> >> >> The old repository was moved to the

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: Unapproved Sharding Sphere releases

> On Feb 7, 2019, at 1:24 PM, Justin Mclean wrote: > > Hi, > >> Prior “Non-Apache Releases” are attached to the repository and come along. >> What to do? I think we have to accept these, but mark them appropriately as >> deleting them would be for the project community during transition. >

Re: Unapproved Sharding Sphere releases

> On Feb 7, 2019, at 11:02 AM, Dave Fisher wrote: > >> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289 >> > > The old repository was moved to the ASF and logically that should also have > moved the legacy

Re: Unapproved Sharding Sphere releases

Hi, > Prior “Non-Apache Releases” are attached to the repository and come along. > What to do? I think we have to accept these, but mark them appropriately as > deleting them would be for the project community during transition. +1 Clearly labelling any non-apache releases prior to the the

Re: Unapproved Sharding Sphere releases

> On Feb 7, 2019, at 10:46 AM, Craig Russell wrote: > > Hi Dave, > >> On Feb 7, 2019, at 9:12 AM, Dave Fisher wrote: >> >> >> >>> On Feb 7, 2019, at 8:31 AM, Craig Russell wrote: >>> >>> >>> On Feb 6, 2019, at 10:31 PM, Justin Mclean wrote: HI, > This

Re: Unapproved Sharding Sphere releases

Hi Dave, > On Feb 7, 2019, at 9:12 AM, Dave Fisher wrote: > > > >> On Feb 7, 2019, at 8:31 AM, Craig Russell wrote: >> >> >> >>> On Feb 6, 2019, at 10:31 PM, Justin Mclean wrote: >>> >>> HI, >>> This was done. The issue is that the "3.0.0 outside Apache" release should not

Re: Unapproved Sharding Sphere releases

> On Feb 7, 2019, at 8:31 AM, Craig Russell wrote: > > > >> On Feb 6, 2019, at 10:31 PM, Justin Mclean wrote: >> >> HI, >> >>> This was done. The issue is that the "3.0.0 outside Apache" release should >>> not be associated with Apache but with the previous project. >> >> They also

Re: Unapproved Sharding Sphere releases

> On Feb 6, 2019, at 10:31 PM, Justin Mclean wrote: > > HI, > >> This was done. The issue is that the "3.0.0 outside Apache" release should >> not be associated with Apache but with the previous project. > > They also made a 3.1.0 release as well and it was on the Apache github site >

[VOTE] Release Apache Dubbo OPS (Incubating) 0.1 [RC3]

Hello Incubator Community, The Apache Dubbo community has voted on and approved a proposal to release Apache Dubbo OPS (Incubating) version 0.1. We now kindly request the Incubator PMC members review and vote on this incubator release. Apache Dubbo™ (incubating) is a high-performance, java

[VOTE] Release Apache Doris 0.9.0-incubating-rc02

Hi all, Please review and vote on Apache Doris 0.9.0-incubating-rc02 release. Apache Doris is an MPP-based interactive SQL data warehousing for reporting and analysis. The Apache Doris community has voted on and approved this release:

Re: [PROPOSAL] New blockchain project: Cava

I suggest to do a PNS as soon as possible, and preferably before the podling is established. Best regards, Pierre Smits *Apache Trafodion , Vice President* *Apache Directory , PMC Member* Apache Incubator

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: Apache ODF Toolkit (retired) migration to TDF

Hi Daniel, Daniel Shahaf wrote: > Also, you might want to update the lists' autoresponders. > That would indeed be helpful - perhaps also with a pointer to odftoolkit.org. > What about this page: > > http://odftoolkit.incubator.apache.org/odftoolkit/index.mdtext > Dunno, is that prominently

Fwd: Draft incubator report

Sorry I meant to send this to the list but only Dave got it. > Begin forwarded message: > > From: Justin Mclean > Subject: Re: Draft incubator report > Date: 6 February 2019 at 8:48:46 am AEDT > To: Dave Fisher > > Hi, > >> Yes, that is better, but here is the next challenge. For