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

[Hongtao Gao]

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  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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
On Thu, Feb 14, 2019, 11:25 AM Justin Mclean  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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

[Justin Mclean]

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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Chris Lambertus]

> On Feb 12, 2019, at 11:36 PM, Justin Mclean  wrote:
> 

>> Does this mean that we need a vote even for distribution of unreleased
>> material ?
> 
> 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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Myrle Krantz]

Weex Mentor here.  Answers inline:

On Wed, Feb 13, 2019 at 8:36 AM Justin Mclean 
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 ?
>
> 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

[Justin Mclean]

Hi,

> We distribute artefacts through *CocoaPods* and *Gradle* channel in
> *incubator-weex*  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 ?

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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[申远]

>
> 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*  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  ?
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  于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-
> /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-
> /tags.
> - Release candidates, nightly or snapshots releases can be tagged and
> appear on https://github.com/apache/incubator-/tags.
>
> Docker
>
> Artefacts need to be placed in https://hub.docker.com/r/apache/
> or https://hub.docker.com/u/apache/
>
> 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/" 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
> 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” 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/
>
> To comply with ASF release and distributions please ensue the following:
> - The project description should include the 

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

[Justin Mclean]

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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Roman Shaposhnik]

On Fri, Feb 8, 2019 at 12:27 PM Justin Mclean 
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  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

[Justin Mclean]

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  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

[Roman Shaposhnik]

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 
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-
> /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-
> /tags.
> - Release candidates, nightly or snapshots releases can be tagged and
> appear on https://github.com/apache/incubator-/tags.
>
> Docker
>
> Artefacts need to be placed in https://hub.docker.com/r/apache/
> or https://hub.docker.com/u/apache/
>

It is unclear whether  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/" 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/" should not install an
artefact containing unapproved code. statement.

Thanks,
Roman.


> NPM
>
> Artefacts  show up on https://www.npmjs.com/package/apache
> 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” 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/
>
> To comply with ASF release and distributions please ensue the following:
> - The project description should include the incubator