You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Justin Mclean <ju...@classsoftware.com> on 2019/02/08 07:07:40 UTC
[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 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.
- 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.
GitHub
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>
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.
- 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.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Fwd: [DISCUSS] Guidelines for distribution of incubating artefacts on
other platforms
Posted by Myrle Krantz <my...@apache.org>.
Hey all,
Since this topic impacts you, I hope you’ll read what Justin wrote and
object if it doesn’t cover your project needs. I know English is hard for
many of you and Apache's processes are also new for you. If you need help
understanding anything written here or help formulating your thoughts, I
will be happy to provide it.
Best Regards,
Myrle
---------- Forwarded message ---------
From: Justin Mclean <ju...@classsoftware.com>
Date: Fri, Feb 8, 2019 at 8:08 AM
Subject: [DISCUSS] Guidelines for distribution of incubating artefacts on
other platforms
To: <ge...@incubator.apache.org>
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.
- 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.
GitHub
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>
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.
- 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.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Guidelines for distribution of incubating artefacts on
other platforms
Posted by Hongtao Gao <ha...@gmail.com>.
Thanks for your effort get them documented. I'm a PPMC member of Apache
SkyWalking and One of my major responsibilities is to distribute docker
image. So this thread fairly help me. I have two questions here.
First is about "Transition Period". When Apache official Dockerhub
repository is created all other illegal repository(eg.
https://hub.docker.com/u/skywalking/ ) should be removed. The end users
will do extra work to change their system, that requires time. So I propose
to give a transition period which maybe between 3 months and half of year.
That's also open for discussion.
Next is about kubernetes. In short I have a plan to use https://hub.helm.sh
to distribute kubernetes yamls for skywalking. This platform seems like
Dockerhub. Could I use it like a Dockerhub? But I don't distribute any
binary or source codes to it except for some kubernetes deloyment yamls.
I'm wondering if helmhub is suitable for the guidelines we discuss here.
Thanks
Hongtao Gao
On Thu, Feb 14, 2019, 11:25 AM Justin Mclean <justin@classsoftware.com
wrote:
> Hi,
>
> > I would like to see his guideline document posted somewhere on cwiki so
> it doesn’t get lost in this thread.
>
> It is [1] if by cwiki you mean wiki.apache.org?
>
> > I would ultimately like both VP Legal and Infra to assess it, so that
> everyone’s on the same page in terms of what’s “allowed,” because right
> now, I think we’re all flying by the seat of our pants.
>
> That was going to be my next steps after the IPMC was happy with it, legal
> already know about it but I’ve not had any feedback from them yet.
>
> Thanks,
> Justin
>
> 1. https://wiki.apache.org/incubator/DistributionGuidelines
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
On Thu, Feb 14, 2019, 11:25 AM Justin Mclean <justin@classsoftware.com
wrote:
> Hi,
>
> > I would like to see his guideline document posted somewhere on cwiki so
> it doesn’t get lost in this thread.
>
> It is [1] if by cwiki you mean wiki.apache.org?
>
> > I would ultimately like both VP Legal and Infra to assess it, so that
> everyone’s on the same page in terms of what’s “allowed,” because right
> now, I think we’re all flying by the seat of our pants.
>
> That was going to be my next steps after the IPMC was happy with it, legal
> already know about it but I’ve not had any feedback from them yet.
>
> Thanks,
> Justin
>
> 1. https://wiki.apache.org/incubator/DistributionGuidelines
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [DISCUSS] Guidelines for distribution of incubating artefacts on
other platforms
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I would like to see his guideline document posted somewhere on cwiki so it doesn’t get lost in this thread.
It is [1] if by cwiki you mean wiki.apache.org?
> I would ultimately like both VP Legal and Infra to assess it, so that everyone’s on the same page in terms of what’s “allowed,” because right now, I think we’re all flying by the seat of our pants.
That was going to be my next steps after the IPMC was happy with it, legal already know about it but I’ve not had any feedback from them yet.
Thanks,
Justin
1. https://wiki.apache.org/incubator/DistributionGuidelines
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Guidelines for distribution of incubating artefacts on
other platforms
Posted by Chris Lambertus <cm...@apache.org>.
> On Feb 12, 2019, at 11:36 PM, Justin Mclean <ju...@classsoftware.com> wrote:
>
>> Does this mean that we need a vote even for distribution of unreleased
>> material <https://www.apache.org/dev/release-distribution#unreleased>?
>
> You are not allowed to distribute unreleased material outside the developer community. [1] I would read that as users being outside the developer community.
OK, IPMC/member hat securely on. I’m not speaking for Infra here.
Releases on dockerhub, NPM, gradle, etc, etc, etc, etc, which are nominally tagged as “convenience binaries” end up being far more widely spread than the “developer community” due to the nature of those systems.
There’s a lot of talk in this else-thread, and a lot of reticence to address the “we release source, not binaries” issue. The reality is that end-users consume binaries. Unless you’re a release manager for a major OS, nobody compiles source anymore. It’s the elephant in the room, and what’s happening now is that binary objects are popping up all over the place. I’m going to pick on Docker because I hate it so much: Infra has allowed a fair bit of leeway here, they previously created only automated builds, but over time have allowed more general access to projects in order to allow them to create nightlies, regenerate builds, and so forth, because it was more efficient and expedient to do so. This is a double edged sword in that we as the Foundation are allowing projects to work with their customer base without undue restriction, but we have essentially zero control over what artifacts are released. Furthermore, I don’t know that we have a lot of ability to stop it, short of curtailing access to the official /u/apache/ namespace and other namespaces that Infra may control.
I think the discussions here and the framework that’s been offered by Justin is a fantastic start, and I’m 100% in favor of it. I would like to see his guideline document posted somewhere on cwiki so it doesn’t get lost in this thread. I would ultimately like both VP Legal and Infra to assess it, so that everyone’s on the same page in terms of what’s “allowed,” because right now, I think we’re all flying by the seat of our pants.
-Chris
>
>> Incubator-weex had used unofficial release without vote to get quick
>> feedback from users before we knew it could break the rule of Apache
>> release. *According to my understanding, any format of release on any
>> platform needs a vote even if it is unofficial, snapshot, nightly build and
>> etc..* Correct me if I am wrong.
>
> Well a snapshots shot or nightly may be OK if it a) not use as a substitute for not voting b) clearly marked so a user wouldn’t assume it a release and c) not placed in the main place user go to to get it. I would guess that the above doesn’t qualify but check with your mentors.
>
> Thanks,
> Justin
>
> 1. https://www.apache.org/dev/release-distribution.html#unreleased
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Guidelines for distribution of incubating artefacts on
other platforms
Posted by Myrle Krantz <my...@apache.org>.
Weex Mentor here. Answers inline:
On Wed, Feb 13, 2019 at 8:36 AM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > We distribute artefacts through *CocoaPods*
I'm with Justin: I'm not familiar with this either, but my first skim
across their information doesn't indicate they'd be fundamentally different
than the other distribution methods. Would you like write access to the
instructions so that you can add them?
> > and *Gradle* channel
Do you mean maven here? These lines in gradle:
dependencies {
...
// weex sdk and fastjson
compile 'com.taobao.android:weex_sdk:0.18.0@aar'
}
draw from a maven repository.
Maven is listed in our instructions.
> Does this mean that we need a vote even for distribution of unreleased
> > material <https://www.apache.org/dev/release-distribution#unreleased>?
>
> You are not allowed to distribute unreleased material outside the
> developer community. [1] I would read that as users being outside the
> developer community.
>
I would reserve judgement here. If it's a limited circle of users who are
consistently QAing your stuff, I'd see them as contributors to the
project. In this case, you should also consider making these people
committers. They are important to the success of your project.
> > Incubator-weex had used unofficial release without vote to get quick
> > feedback from users before we knew it could break the rule of Apache
> > release. *According to my understanding, any format of release on any
> > platform needs a vote even if it is unofficial, snapshot, nightly build
> and
> > etc..* Correct me if I am wrong.
>
> Well a snapshots shot or nightly may be OK if it a) not use as a
> substitute for not voting b) clearly marked so a user wouldn’t assume it a
> release and c) not placed in the main place user go to to get it. I would
> guess that the above doesn’t qualify but check with your mentors.
>
Users can be involved in your QA process. If select users are downloading
your stuff and giving feedback, that's fine. However if you've been
advertising your stuff more broadly (for example by referencing unreleased
versions it in your getting started guide), you've been "breaking the
rules".
If that's the case, I'm fairly certain you didn't intend to. So it should
be easy to fix. In the case of the website example: just revert the
website examples to reference properly released versions.
If you have any questions, I'm here to help.
Best Regards,
Myrle
Weex Mentor
Re: [DISCUSS] Guidelines for distribution of incubating artefacts on
other platforms
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> We distribute artefacts through *CocoaPods* and *Gradle* channel in
> *incubator-weex* <http://incubator.apache.org/projects/weex.html> project
> for iOS and Android developers. It would be great if you could add
> *CocoaPods* and *Gradle *platforms.
I'm not familiar with those distribution method in details, looking at the top general guidelines could you come up with some that follow those?
> Does this mean that we need a vote even for distribution of unreleased
> material <https://www.apache.org/dev/release-distribution#unreleased>?
You are not allowed to distribute unreleased material outside the developer community. [1] I would read that as users being outside the developer community.
> Incubator-weex had used unofficial release without vote to get quick
> feedback from users before we knew it could break the rule of Apache
> release. *According to my understanding, any format of release on any
> platform needs a vote even if it is unofficial, snapshot, nightly build and
> etc..* Correct me if I am wrong.
Well a snapshots shot or nightly may be OK if it a) not use as a substitute for not voting b) clearly marked so a user wouldn’t assume it a release and c) not placed in the main place user go to to get it. I would guess that the above doesn’t qualify but check with your mentors.
Thanks,
Justin
1. https://www.apache.org/dev/release-distribution.html#unreleased
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Guidelines for distribution of incubating artefacts on
other platforms
Posted by 申远 <sh...@gmail.com>.
>
> 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.
We distribute artefacts through *CocoaPods* and *Gradle* channel in
*incubator-weex* <http://incubator.apache.org/projects/weex.html> project
for iOS and Android developers. It would be great if you could add
*CocoaPods* and *Gradle *platforms.
- Unofficial releases need to be made from approved voted on approved ASF
> releases.
Does this mean that we need a vote even for distribution of unreleased
material <https://www.apache.org/dev/release-distribution#unreleased> ?
Incubator-weex had used unofficial release without vote to get quick
feedback from users before we knew it could break the rule of Apache
release. *According to my understanding, any format of release on any
platform needs a vote even if it is unofficial, snapshot, nightly build and
etc..* Correct me if I am wrong.
Best Regards,
YorkShen
申远
Justin Mclean <ju...@classsoftware.com> 于2019年2月8日周五 下午3:08写道：
> 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.
> - 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.
>
> GitHub
>
> 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>
>
> 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.
> - 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.
>
> 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [DISCUSS] Guidelines for distribution of incubating artefacts on
other platforms
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> - Convenience binary artifact releases need to be made from approved voted
> on approved ASF releases.
OK.
> Wait, you mean binary releases, not just source code tags?
Binary releases [1] (see step 7) and unapproved release are possible in GitHub.
Once I get some more feedback I’l put this up on a wiki page.
Thanks,
Justin
1. https://help.github.com/articles/creating-releases/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Guidelines for distribution of incubating artefacts on
other platforms
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Feb 8, 2019 at 12:27 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > This sentence is very confusing to me. If the release is "unofficial”
> then it can't be subject to ASF's policy, no?
>
> I used the word unofficial as some of these artefacts are connivance
> binaries. I and don’t want to open up the “we only release source" can of
> worms.
>
Then why not just call them what they are "convenience binary artifacts".
IOW, how about this edit:
- Convenience binary artifact releases need to be made from approved voted
on approved ASF releases.
?
>
> > I am actually not sure why we're including GitHub in this list.
>
> Because people are placing releases there as well. Github has a release
> page which can include release notes etc and shows a history of releases,
> users can download releases from here.
>
Wait, you mean binary releases, not just source code tags?
>
> > It is unclear whether <project> should include incubator- prefix. I
> > honestly thing it should.
>
> Good point. None of them I’ve seen have, I was thinking not and then you
> need to rename on graduation which would be a pain.
>
> > You don't have to had a Dockerfile to publish to Docker Hub. This
> sentence
> > makes it sound like it is a requirement.
>
> Right I’ll make that optional.
>
> Thanks for the feedback.
> Justin
Re: [DISCUSS] Guidelines for distribution of incubating artefacts on
other platforms
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> This sentence is very confusing to me. If the release is "unofficial” then it can't be subject to ASF's policy, no?
I used the word unofficial as some of these artefacts are connivance binaries. I and don’t want to open up the “we only release source" can of worms.
> I am actually not sure why we're including GitHub in this list.
Because people are placing releases there as well. Github has a release page which can include release notes etc and shows a history of releases, users can download releases from here.
> It is unclear whether <project> should include incubator- prefix. I
> honestly thing it should.
Good point. None of them I’ve seen have, I was thinking not and then you need to rename on graduation which would be a pain.
> You don't have to had a Dockerfile to publish to Docker Hub. This sentence
> makes it sound like it is a requirement.
Right I’ll make that optional.
Thanks for the feedback.
Justin
Re: [DISCUSS] Guidelines for distribution of incubating artefacts on
other platforms
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
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 <ju...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>