[ 
https://issues.apache.org/jira/browse/GUACAMOLE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15499782#comment-15499782
 ] 

Michael Jumper edited comment on GUACAMOLE-97 at 9/17/16 10:18 PM:
-------------------------------------------------------------------

Copying and consolidating Marvin's helpful replies from the mailing list thread 
below.

[From 
2017-09-07|http://mail-archives.apache.org/mod_mbox/incubator-general/201609.mbox/%3CCAAS6=7hekbOQMfuuxN3cX52KjqkT23=_4xeyrdzkny6qsnx...@mail.gmail.com%3E]:

{quote}
{noformat}
> are there any specific opinions regarding
> the original issue: the actual namespacing of the podling images
> themselves?

>     apache/incubator-guacamole:0.9.10-incubating
>     apache/incubator-guacd:0.9.10-incubating

Using how we name Git repos as precedent, the image address would be:

    apache/incubator-guacamole
    apache/incubator-guacamole-guacd

... and with tags:

    apache/incubator-guacamole:0.9.10-incubating
    apache/incubator-guacamole-guacd:0.9.10-incubating

>     - Seems redundant (incubator, incubating), graduation would break
>       compatibility (see Maven best practices [1])

I agree that it would be best not to break compat on graduation.

>     apache/guacamole:0.9.10-incubating
>     apache/guacd:0.9.10-incubating

Or, matching up with our (post-graduation) Git repo naming
convention again:

    apache/guacamole
    apache/guacamole-guacd

    apache/guacamole:0.9.10-incubating
    apache/guacamole-guacd:0.9.10-incubating

I think this is best.  However, it bugs me that users are not provided with
adequate disclaimers for the common case that fetches `latest` as the default
tag:

    docker pull apache/guacamole

I don't have any ideas beyond requiring a prominent incubation disclaimer on
the repo info page at https://hub.docker.com/r/apache/$REPO/ .
{noformat}
{quote}

And [further clarifying on 
2016-09-08|http://mail-archives.apache.org/mod_mbox/incubator-general/201609.mbox/%3CCAAS6=7iSLDDK+hcxCW33yXMgeJZn_kMxX=x+wjdizh_vss6...@mail.gmail.com%3E]:

{quote}
{noformat}
> Is the project-specific organization option not really an option at all
> then? Frowned upon for a TLP, and not to be considered by a podling?

My chief concern so far has been assuring that our nascent Infra-supported
offerings do not conflict with policy.  Now that this has been achieved (in
planning, if not yet in implementation), it's easier to speak to your issue.

The main Docker Hub at hub.docker.com is a public-facing downstream
distribution channel -- similar to Maven Central, PyPI, Debian package
management, etc.

It is appropriate to distribute official releases through downstream channels,
but inappropriate to distribute unreleased materials through them.  (That's
why having `latest` on hub.docker.com point to git `master` is problematic.)
See Apache's formal Release Policy and Release Distribution Policy documents:

    http://www.apache.org/legal/release-policy#policy
    http://www.apache.org/dev/release-distribution#policy

There are an unbounded number of such downstream channels, and there is no way
we are going to formulate specific policies for all of them.  Instead, we
primarily rely on people respecting our trademarks: that "Apache Foo", when
obtained from one of these channels, is what the consumer expects.

    http://www.apache.org/foundation/marks

One implication is that if you're using the project name for that Docker
Hub account, we'd expect the entire PMC to have access.

Incubating podlings operate under additional constraints, in that the "Apache"
brand needs to be tempered with "incubating" and appropriate disclaimers.

    http://incubator.apache.org/guides/branding.html

But within those guidelines, the answer is: yes, go ahead.  If Infra's
offering is not to your taste, that is.
{noformat}
{quote}

As long as the PMC has full access to the organization, a project-specific 
organization is fine.

EDIT: Within the above-quoted guidelines, of course.


was (Author: mike.jumper):
Copying and consolidating Marvin's helpful replies from the mailing list thread 
below.

[From 
2017-09-07|http://mail-archives.apache.org/mod_mbox/incubator-general/201609.mbox/%3CCAAS6=7hekbOQMfuuxN3cX52KjqkT23=_4xeyrdzkny6qsnx...@mail.gmail.com%3E]:

{quote}
{noformat}
> are there any specific opinions regarding
> the original issue: the actual namespacing of the podling images
> themselves?

>     apache/incubator-guacamole:0.9.10-incubating
>     apache/incubator-guacd:0.9.10-incubating

Using how we name Git repos as precedent, the image address would be:

    apache/incubator-guacamole
    apache/incubator-guacamole-guacd

... and with tags:

    apache/incubator-guacamole:0.9.10-incubating
    apache/incubator-guacamole-guacd:0.9.10-incubating

>     - Seems redundant (incubator, incubating), graduation would break
>       compatibility (see Maven best practices [1])

I agree that it would be best not to break compat on graduation.

>     apache/guacamole:0.9.10-incubating
>     apache/guacd:0.9.10-incubating

Or, matching up with our (post-graduation) Git repo naming
convention again:

    apache/guacamole
    apache/guacamole-guacd

    apache/guacamole:0.9.10-incubating
    apache/guacamole-guacd:0.9.10-incubating

I think this is best.  However, it bugs me that users are not provided with
adequate disclaimers for the common case that fetches `latest` as the default
tag:

    docker pull apache/guacamole

I don't have any ideas beyond requiring a prominent incubation disclaimer on
the repo info page at https://hub.docker.com/r/apache/$REPO/ .
{noformat}
{quote}

And [further clarifying on 
2016-09-08|http://mail-archives.apache.org/mod_mbox/incubator-general/201609.mbox/%3CCAAS6=7iSLDDK+hcxCW33yXMgeJZn_kMxX=x+wjdizh_vss6...@mail.gmail.com%3E]:

{quote}
{noformat}
> Is the project-specific organization option not really an option at all
> then? Frowned upon for a TLP, and not to be considered by a podling?

My chief concern so far has been assuring that our nascent Infra-supported
offerings do not conflict with policy.  Now that this has been achieved (in
planning, if not yet in implementation), it's easier to speak to your issue.

The main Docker Hub at hub.docker.com is a public-facing downstream
distribution channel -- similar to Maven Central, PyPI, Debian package
management, etc.

It is appropriate to distribute official releases through downstream channels,
but inappropriate to distribute unreleased materials through them.  (That's
why having `latest` on hub.docker.com point to git `master` is problematic.)
See Apache's formal Release Policy and Release Distribution Policy documents:

    http://www.apache.org/legal/release-policy#policy
    http://www.apache.org/dev/release-distribution#policy

There are an unbounded number of such downstream channels, and there is no way
we are going to formulate specific policies for all of them.  Instead, we
primarily rely on people respecting our trademarks: that "Apache Foo", when
obtained from one of these channels, is what the consumer expects.

    http://www.apache.org/foundation/marks

One implication is that if you're using the project name for that Docker
Hub account, we'd expect the entire PMC to have access.

Incubating podlings operate under additional constraints, in that the "Apache"
brand needs to be tempered with "incubating" and appropriate disclaimers.

    http://incubator.apache.org/guides/branding.html

But within those guidelines, the answer is: yes, go ahead.  If Infra's
offering is not to your taste, that is.
{noformat}
{quote}

As long as the PMC has full access to the organization, a project-specific 
organization is fine.

> Update documentation for Docker images
> --------------------------------------
>
>                 Key: GUACAMOLE-97
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-97
>             Project: Guacamole
>          Issue Type: Task
>          Components: Documentation, guacamole-docker, guacd-docker
>            Reporter: Michael Jumper
>            Assignee: Michael Jumper
>            Priority: Blocker
>             Fix For: 0.9.10-incubating
>
>
> There is an [ongoing discussion in the incubator general mailing 
> list|http://mail-archives.apache.org/mod_mbox/incubator-general/201608.mbox/%3CCALKeL-OEzMr_ERZbA0NowPS7Xux%3Df_HG%2Bg_dLuWtn1j_fA_z2Q%40mail.gmail.com%3E]
>  regarding how Docker images of podlings can be distributed. Once that is 
> settled, the manual and per-image documentation must be brought up-to-date.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to