Re: [VOTE] Distribution guidelines for platforms
> > Personally, I believe that interpretation is still making new rules. > Please point to one of these new rules. Again, in my opinion, the act of interpretation of existing rules in a new context is making new rules. Thus, all the rules in the guidelines are new rules. > > As a podling PPMC member, my main concern from the disagreement in this > > thread is that we may end up > > seeing podlings being bound by additional rules that the top-level projects > > are not bound to. > Well another alternative I see is to ban the use of all alternative channels > until we do have ASF policy in place for their use. I don’t think projects > would be happy with that. I'm not sure whether that would be the only alternative. If this is indeed the case, I think it would be extremely concerning if the incubator is to ban all podlings from using non-ASF distribution channels. It would be an act that forces podlings that rely on non-ASF distribution channels to retire, making the name "incubator" rather insincere to them, if not ironic. Best, Sheng On 2020/07/13 05:38:16, Justin Mclean wrote: > Hi, > > > This description suggests that the nature of this guideline is the > > interpretation of the > > existing Apache policies in the context of distribution on third-party > > platform. > > That is correct. > > > Personally, I believe that interpretation is still making new rules. > > Please point to one of these new rules. Everything in come from existing ASF > policy put into context for these platforms. This is advice to help projects > comply with policy. Some podlings are currently not doing that. How else > would you suggest we fix that? > > > As a podling PPMC member, my main concern from the disagreement in this > > thread is that we may end up > > seeing podlings being bound by additional rules that the top-level projects > > are not bound to. > > Well another alternative I see is to ban the use of all alternative channels > until we do have ASF policy in place for their use. I don’t think projects > would be happy with that. > > Thanks, > Justin > - > 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: [VOTE] Distribution guidelines for platforms
Hi, > This description suggests that the nature of this guideline is the > interpretation of the > existing Apache policies in the context of distribution on third-party > platform. That is correct. > Personally, I believe that interpretation is still making new rules. Please point to one of these new rules. Everything in come from existing ASF policy put into context for these platforms. This is advice to help projects comply with policy. Some podlings are currently not doing that. How else would you suggest we fix that? > As a podling PPMC member, my main concern from the disagreement in this > thread is that we may end up > seeing podlings being bound by additional rules that the top-level projects > are not bound to. Well another alternative I see is to ban the use of all alternative channels until we do have ASF policy in place for their use. I don’t think projects would be happy with that. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Distribution guidelines for platforms
Hi Justin, While I appreciate your efforts in putting together the guidelines, your reply seems to indicate that this guideline is not making new rules, which is apparently false. Specifically, you wrote: > Nothing as far as I can see is added only clarified and put into context for > different 3rd party > platforms. This description suggests that the nature of this guideline is the interpretation of the existing Apache policies in the context of distribution on third-party platform. Personally, I believe that interpretation is still making new rules. After all, statutory interpretation is one of the main ways for making laws in common law legal system. As a podling PPMC member, my main concern from the disagreement in this thread is that we may end up seeing podlings being bound by additional rules that the top-level projects are not bound to. My preference on how things should unfold, as I mentioned in the discussion thread, is still to see the consensus built in the overall Apache policies that binds everyone, not just the podlings. Best regards, Sheng On 2020/07/12 22:35:34, Justin Mclean wrote: > Hi, > > > A reference to http://www.apache.org/dev/#releases ought to be first from > > any incubator policy or guidance page. Problems with the dev page should be > > addressed. If the Foundation wide policy and guidance is weak then that > > should be fixed so that an Incubating podlings can use the proper > > information. > > These guidelines are about distribution of releases not making releases. The > incubator already has guidelines about releases [1] and it does reference > http://www.apache.org/dev/#releases at the top. This information does not > replace that. But yes referencing [2] (ASF distribution policy) is a good > idea. > > > To me the only way that the Incubator policy guidance differs from ASF > > policy guidance is: > > > > - Disclaimers > > - IPMC vote on releases on general@ > > - Allowing non-Apache legacy releases in transition. > > Also: > - How PPMC member are elected > - How press announced can be made > - Branding and trademark > > And guidance on how to follow other ASF policies. Mentors and IPMC members do > that all the time. This document helps in that regard and there is nothing in > this document that isn’t in policy elsewhere. > > > I agree that guidance would be helpful for distribution channels other than > > those Infrastructure supports, but that guidance should be at the > > Foundation level. > > The Incubator has waited years for something to happen, the current draft > policy doesn’t address this, nor is it our remit to fix that policy. Do we > just postpone all project graduations that use other methods of distribution > while we wait? Or prohibit them altogether? Or do we provide best practice > guidances that has input from the IPMC, legal and trademarks and has been > discussed on and off for over a year? > > Currently we have more than one podling that are not following ASF policy on > releases and distribution. If they were pointed to and followed this document > they would have be in compliance. > > Thanks, > Justin > > 1. https://incubator.apache.org/policy/incubation.html > 2. https://infra.apache.org/release-distribution > - > 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
[jira] [Commented] (INCUBATOR-253) Issues with MXNet releases and their distribution
[ https://issues.apache.org/jira/browse/INCUBATOR-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17156491#comment-17156491 ] Justin Mclean commented on INCUBATOR-253: - It's really going to depend on the details and intent. Basically just because it allowed doesn't mean you should do to avoid other aspects of ASF policy on releases. These 3rd party releases could also bring along with them an increased possible risk with licensing, security, user confusion who owns the project, damage to the ASF brand and and a number of other issues. They would also probably mean more work for the (P)PMC on managing it's brand. > Issues with MXNet releases and their distribution > - > > Key: INCUBATOR-253 > URL: https://issues.apache.org/jira/browse/INCUBATOR-253 > Project: Incubator > Issue Type: Improvement >Reporter: Justin Mclean >Assignee: Justin Mclean >Priority: Major > > The main issues are: > 1. Source and convenance binary releases containing Category X licensed code. > 2. Website giving access to downloads of non released/unapproved code. > 3. Website giving access to releases containing Category X licensed code. > 4. Web site doesn't given enough warning to users of the issues with non > (P)PMC releases or making it clear that these are not ASF releases. > 5. Maven releases containing Category X licensed code. > 6. PiPy releases containing Category X licensed code. > 7. Docker releases containing Category X licensed code. > 8 Docker releases containing unreleased/unapproved code. > 9. Trademark and branding issues with PiPy and Docker releases. > 10. Trademark and brand issues with naming of releases. > 11. Developer releases available to users and public searchable > https://repo.mxnet.io / https://dist.mxnet.io > 12. Releases and other nightly builds on https://repo.mxnet.io / > https://dist.mxnet.io containing category X licensed code. > 13. Lack of clarity on all platforms for what is an ASF release and what is > not. > 14. Branding and release of 3rd parties containing unreleased code. (e.g. > https://docs.nvidia.com/deeplearning/frameworks/mxnet-release-notes/rel_20-03.html) > For PiPy see: > https://pypi.org/project/mxnet/ > For Docker see: > https://hub.docker.com/u/mxnet > For web site pages see: > https://mxnet.apache.org/get_started? > https://mxnet.apache.org/get_started/download > I may of missed something, if so please add it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Commented] (INCUBATOR-253) Issues with MXNet releases and their distribution
[ https://issues.apache.org/jira/browse/INCUBATOR-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17156483#comment-17156483 ] Sheng Zha commented on INCUBATOR-253: - [~jmclean] you added some notes to it and I'd like to continue the discussion here. You wrote: > But I have two concerns ... b) branding all release as "3rd party" may not be > the best way to solve the issue. First, I'd like to clarify that the claim is inaccurate in that we are not classifying all releases as "3rd party". For example, the source releases are still very much first party and we only make official source releases. In addition, assuming that you actually referred to convenience binary releases, I'd like to understand more on why having third-party handle the binary releases for our releases is "not the best". It serves the needs of our community for faster installation and the fact of having third-party releases does not appear to be forbidden in the overall policies in Apache. Could you be more specific on what your concerns are? > Issues with MXNet releases and their distribution > - > > Key: INCUBATOR-253 > URL: https://issues.apache.org/jira/browse/INCUBATOR-253 > Project: Incubator > Issue Type: Improvement >Reporter: Justin Mclean >Assignee: Justin Mclean >Priority: Major > > The main issues are: > 1. Source and convenance binary releases containing Category X licensed code. > 2. Website giving access to downloads of non released/unapproved code. > 3. Website giving access to releases containing Category X licensed code. > 4. Web site doesn't given enough warning to users of the issues with non > (P)PMC releases or making it clear that these are not ASF releases. > 5. Maven releases containing Category X licensed code. > 6. PiPy releases containing Category X licensed code. > 7. Docker releases containing Category X licensed code. > 8 Docker releases containing unreleased/unapproved code. > 9. Trademark and branding issues with PiPy and Docker releases. > 10. Trademark and brand issues with naming of releases. > 11. Developer releases available to users and public searchable > https://repo.mxnet.io / https://dist.mxnet.io > 12. Releases and other nightly builds on https://repo.mxnet.io / > https://dist.mxnet.io containing category X licensed code. > 13. Lack of clarity on all platforms for what is an ASF release and what is > not. > 14. Branding and release of 3rd parties containing unreleased code. (e.g. > https://docs.nvidia.com/deeplearning/frameworks/mxnet-release-notes/rel_20-03.html) > For PiPy see: > https://pypi.org/project/mxnet/ > For Docker see: > https://hub.docker.com/u/mxnet > For web site pages see: > https://mxnet.apache.org/get_started? > https://mxnet.apache.org/get_started/download > I may of missed something, if so please add it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Release Apache NuttX (Incubating) 9.1.0 [RC2]
Hello all, This is a call for a vote to release Apache NuttX (Incubating) version 9.1.0. The Apache NuttX community has voted on and approved a proposal to release Apache NuttX (Incubating) version 9.1.0. We now kindly request the Incubator PMC members review and vote on this incubator release. NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 64-bit microcontroller environments, the primary governing standards in NuttX are Posix and ANSI standards. Additional standard APIs from Unix and other common RTOS’s (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply- embedded environments (such as fork()). Because this project targets embedded systems there is more complexity involved in the build process. Two starting points: * README.txt -- This is found in the Apache NuttX source and is extensive. * Unofficial NuttX Companion -- https://nuttx-companion.readthedocs.io/en/latest/user/install.html, this is a currently unofficial opinionated guide maintained by some of the project committers. Apache NuttX community vote and result thread: Result: https://lists.apache.org/thread.html/r1a30e5cba2dab57556605fb6570fd722de1eee69244c1b4092579033%40%3Cdev.nuttx.apache.org%3E Vote: https://lists.apache.org/thread.html/r751f7ce05b1f0485b5dc9ca7bfb1c5f52abc5676fd81b9fb92910c64%40%3Cdev.nuttx.apache.org%3E The release candidates (RC2): https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.1.0-RC2/ Git tag for the release (RC2): https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.1.0-RC2 https://github.com/apache/incubator-nuttx-apps/releases/tag/nuttx-9.1.0-RC2 Hash for the release incubating-nuttx tag: e4e4cce6962430e2b07336d2c564b14298995661 Hash for the release incubating-nuttx-apps tag: 4fac1c185c01adfa84f04618af9be7b9c4b884f5 Release Notes: https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-9.1.0-RC2/ReleaseNotes The artifacts have been signed with Key : 3554D78458CEB6954B020E12E1B6E30DB05D6280, which can be found in the keys file: https://dist.apache.org/repos/dist/dev/incubator/nuttx/KEYS Look at here for how to verify this release candidate: https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release The vote will be open for at least 72 hours. Please vote accordingly: [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove with the reason Brennan Ashton Apache NuttX - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Distribution guidelines for platforms
Hi, > A reference to http://www.apache.org/dev/#releases ought to be first from any > incubator policy or guidance page. Problems with the dev page should be > addressed. If the Foundation wide policy and guidance is weak then that > should be fixed so that an Incubating podlings can use the proper information. These guidelines are about distribution of releases not making releases. The incubator already has guidelines about releases [1] and it does reference http://www.apache.org/dev/#releases at the top. This information does not replace that. But yes referencing [2] (ASF distribution policy) is a good idea. > To me the only way that the Incubator policy guidance differs from ASF policy > guidance is: > > - Disclaimers > - IPMC vote on releases on general@ > - Allowing non-Apache legacy releases in transition. Also: - How PPMC member are elected - How press announced can be made - Branding and trademark And guidance on how to follow other ASF policies. Mentors and IPMC members do that all the time. This document helps in that regard and there is nothing in this document that isn’t in policy elsewhere. > I agree that guidance would be helpful for distribution channels other than > those Infrastructure supports, but that guidance should be at the Foundation > level. The Incubator has waited years for something to happen, the current draft policy doesn’t address this, nor is it our remit to fix that policy. Do we just postpone all project graduations that use other methods of distribution while we wait? Or prohibit them altogether? Or do we provide best practice guidances that has input from the IPMC, legal and trademarks and has been discussed on and off for over a year? Currently we have more than one podling that are not following ASF policy on releases and distribution. If they were pointed to and followed this document they would have be in compliance. Thanks, Justin 1. https://incubator.apache.org/policy/incubation.html 2. https://infra.apache.org/release-distribution - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Distribution guidelines for platforms
Hi Justin, To me the Foundation Dev Guidance comes first and it is currently buried within the Incubator policy and guidance. A reference to http://www.apache.org/dev/#releases ought to be first from any incubator policy or guidance page. Problems with the dev page should be addressed. If the Foundation wide policy and guidance is weak then that should be fixed so that an Incubating podlings can use the proper information. To me the only way that the Incubator policy guidance differs from ASF policy guidance is: - Disclaimers - IPMC vote on releases on general@ - Allowing non-Apache legacy releases in transition. I agree that guidance would be helpful for distribution channels other than those Infrastructure supports, but that guidance should be at the Foundation level. Anything put out just for the Incubator may run into other issues in the future and could lead to confusion or conflict. Regards, Dave > On Jul 11, 2020, at 7:55 PM, Justin Mclean wrote: > > HI, > >> This lacks proper reference to existing Apache Policies and instead rewrites >> it. > > There no rewriting here. If you want reference to policies does this work for > you? > > "In addition to the Apache mirror system incubating projects may distribute > artifacts on other platforms as long as they follow these general guidelines: > • Releases must be placed in the Apache mirror system. [1] > • Source releases and convenience binaries need to be made from > IPMC and PPMC approved ASF releases.[2][3] > • Where possible it should be pointed out that Apache project > make source releases and convenience binaries are just a convenience for end > user.[4] > • Convenience binaries need to follow licensing policy and not > include any category X licensed software. [5] > • Convenience binaries should be signed and have hashes to verify > their contents. [6] > • Release candidates, nightlys and snapshots must not be > advertised to the general public.[7] > • Apache project branding and naming needs to be respected. [8] > • It should be clear that the artifacts are under the ALv2 > license.[9] > • An incubating disclaimer must be clearly displayed where the > artifacts are made available. [10] > • All PPMC members must have access to administer the platform > and the credentials recorded where any PPMC member can access them. [11] > • Where possible these artifacts should not be referred to as > releases.[12] > • Where possible use platforms officially supported by Infra. [13] > > All of the above SHOULD be followed. The podling can ask the IPMC for > permission to do otherwise.” > > Again this is to help podling comply with existing policy and does not > rewrite it. > > Thanks, > Justin > > 1. https://infra.apache.org/release-distribution#public-distribution > 2. http://www.apache.org/legal/release-policy.html#release-approval > 3. https://incubator.apache.org/policy/incubation.html#releases > 4. http://www.apache.org/legal/release-policy.html#compiled-packages > 5. https://www.apache.org/legal/resolved.html#category-x > 6. https://infra.apache.org/release-distribution#public-distribution > 7. http://www.apache.org/legal/release-policy.html#publication > 8 https://www.apache.org/foundation/marks/responsibility#compliance > 9 http://www.apache.org/legal/release-policy.html#licensing > 10 https://incubator.apache.org/policy/incubation.html#disclaimers > 11. https://community.apache.org/projectIndependence.html > 12. http://www.apache.org/legal/release-policy.html#what > 13. > https://lists.apache.org/thread.html/r47051fbdb8ebd6dc9a6b4ef1f35aa9f51fb3fe6e1a08254022452164%40%3Cusers.infra.apache.org%3E > (currently a PR on that policy to make this clearer) > - > 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] project proposal - Apache Sedona
Hi - You note over 30 contributors to GeoSpark, but there are only 8 initial committers. Has the move to the Apache Incubator been thoroughly discussed in the existing community? Is anyone being excluded? Best Regards, Dave Sent from my iPhone > On Jul 12, 2020, at 12:36 PM, Felix Cheung wrote: > > Any questions or concerns? If not, I can kick off the VOTE thread shortly. > > > >> On Thu, Jul 9, 2020 at 6:12 AM Felix Cheung wrote: >> >> Hi, >> >> We would like to propose Apache Sedona, currently known in its community >> as GeoSpark, as a new project under the Apache Incubator. >> >> Sedona is a big geospatial data processing engine. The system provides an >> easy to use Scala, SQL, and Python APIs for spatial data scientists to >> manage, wrangle, and process geospatial data. The system extends and builds >> upon a popular cluster computing framework (Apache Spark) to provide >> scalability. >> >> >> The proposal can be found at >> https://cwiki.apache.org/confluence/display/INCUBATOR/Sedona+Proposal >> >> The project can benefit from and is seeking more experienced mentor. >> >> Any thought or feedback is appreciated! >> Regards >> Felix >> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] project proposal - Apache Sedona
Any questions or concerns? If not, I can kick off the VOTE thread shortly. On Thu, Jul 9, 2020 at 6:12 AM Felix Cheung wrote: > Hi, > > We would like to propose Apache Sedona, currently known in its community > as GeoSpark, as a new project under the Apache Incubator. > > Sedona is a big geospatial data processing engine. The system provides an > easy to use Scala, SQL, and Python APIs for spatial data scientists to > manage, wrangle, and process geospatial data. The system extends and builds > upon a popular cluster computing framework (Apache Spark) to provide > scalability. > > > The proposal can be found at > https://cwiki.apache.org/confluence/display/INCUBATOR/Sedona+Proposal > > The project can benefit from and is seeking more experienced mentor. > > Any thought or feedback is appreciated! > Regards > Felix > >
[ANNOUNCE] Apache Annotator (incubating) 0.1.0 release
Dear community, The Apache Annotator (incubating) community is pleased to announce the release of Apache Annotator (incubating) 0.1.0. Apache Annotator (incubating) provides libraries to enable annotation related software, with an initial focus on identification of textual fragments in browser environments. The 0.1.0 release of Apache Annotator (incubating) is the first release of the project and is intended for early adopters, testers and contributors who are interested in helping shape the future of the project. Please reach out to the community on the project development list for help getting started working with the project or to get involved in its development. Download links: https://annotator.apache.org/ The release tag: https://github.com/apache/incubator-annotator/releases/tag/v0.1.0 With regards on behalf of the Apache Annotator (incubating) team, Randall Leeds - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
