Great effort getting it all documented! Would really love to see this converge ASAP.
On Thu, Feb 7, 2019 at 11:08 PM Justin Mclean <jus...@classsoftware.com> wrote: > 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 platform please do so, but these are one we’ve > recently had issues with that I’m aware of. > > Currently not many projects would be complying with this, for instance > most likely missing the incubator disclaimer, which I think is importtant. > > Does the IPMC think we need to have a vote on approving this? > > I've added a harsh non-compliance to hopefully smart how important this is > and to reduce the risk to the ASF. If you think it is too harsh or not > needed speak up. > > > ---------------------------------------------------------------------------------------------------------- > Guidelines to help you comply with the ASF release and distribution > policies > > In addition to the Apache mirror system incubating projects may distribute > artefacts on other platforms as long as they follow these general > guidelines: > - Unofficial releases need to be made from approved voted on approved ASF > releases. > This sentence is very confusing to me. If the release is "unofficial" then it can't be subject to ASF's policy, no? > - An incubating disclaimer must be clearly be displayed where the > artefacts are made available. > - Release candidates, nightlys and snapshots must not be advertised to the > general public. - Apache project branding and naming needs to be respected. > - It should be clear that the artefact in under the ALv2 license. > - Where possible these artefacts should not be referred to as releases. > > If any podling is found not to comply they will be asked to fix it, if a > fix doesn’t happen with a week they will be asked to remove the offending > artefact(s), if a podling commits serial offences or fails to remove > artefacts when asked to within a week they will be banned from using that > distribution mechanism altogether. > I would also ask that if after a certain period of time the podling doesn't respond to criticism -- IPMC reserves the right to ask INFRA to remove the artifact. > > GitHub > I am actually not sure why we're including GitHub in this list. For all practical purposes, GitHub is a mirror of ASF git repo and as such doesn't warrant a dedicated policy. I'd like to see it removed. > Artifacts show up on https://github.com/apache/incubator- > <project>/releases > > To comply with ASF release and distributions please ensue the following: > - Any releases need to include the text of the incubation disclaimer. > - The release page must not contain release candidates, nightly or > snapshots releases. > - Any releases that exist before coming into incubation need to be clearly > described and tagged as such on https://github.com/apache/incubator- > <project>/tags. > - Release candidates, nightly or snapshots releases can be tagged and > appear on https://github.com/apache/incubator-<project>/tags. > > Docker > > Artefacts need to be placed in https://hub.docker.com/r/apache/<project> > or https://hub.docker.com/u/apache<project>/<project> > It is unclear whether <project> should include incubator- prefix. I honestly thing it should. > To comply with ASF release and distributions please ensue the following: > - The overview should include the incubator disclaimer. > - The docker file should include an ASF header. > You don't have to had a Dockerfile to publish to Docker Hub. This sentence makes it sound like it is a requirement. > - The docker file should include the incubator disclaimer. > - "docker pull apache/<project>" should not install an artefact containing > unapproved code. > - Release candidates, nightly or snapshots need to be clearly tagged. - The latest tag should not point to an artefact containing unapproved code > e.g. to master or dev branches or to a RC or snapshot. > This is a repeat of a "docker pull apache/<project>" should not install an artefact containing unapproved code. statement. Thanks, Roman. > NPM > > Artefacts show up on https://www.npmjs.com/package/apache<project> > version page > > To comply with ASF release and distributions please ensue the following: > - The readme tab needs to include the text of the incubation disclaimer. > - “npm install apache<project>” should not install an artefact containing > unapproved code. > - The latest release should not point to an artefact containing unapproved > code e.g. a release candidate or snapshot. > - Release candidates, nightly or snapshots need to be clearly tagged. > - The license field should display the ALv2 license. > > PiPy > > Artefacts need to be placed in https://pypi.org/project/apache<project>/ > > To comply with ASF release and distributions please ensue the following: > - The project description should include the incubator disclaimer. > - “pip install apache<project>" should not install an artefact containing > unapproved code. > - Release candidates, nightly or snapshots need to be clearly tagged as > pre-release on https://pypi.org/project/apaceh<project>/#history > - The latest version should not point to an artefact containing unapproved > code e.g. to a release candidate or snapshot > - The meta license field should display the ALv2 license. > ————————————————————————————————————————————————————— > > Once the discussion has died down I'll run this past infra and legal and > see if they are fine with it and then bring it to the boards attention. > > Thanks, > Justin > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
