I found the original discussion for this guideline[1], and I respect that the Incubator did such pioneer works to provide a base to discuss and evolve.
The proposal here is to improve the expression on NPM / PyPI for the package name to be either: 1. apache-projectname 2. projectname or loosely a combination of "apache" and "projectname" (think of @apachedubbo/dubbo above). The main purpose for these sentences IMO is to emphasize the Apache branding. We can advice podlings to populate/update metadata with ASF branding that doesn't break current usage (pip install xxx; npm install xxx). If the verified organization is significant, we should push forward work like [2] or other methods (NPM's @apache scope, Crates.io add @apache/project-committers as owner) according to the platform's flavor. Best, tison. [1] https://lists.apache.org/thread/jl2y439207vvzlrnlpvtq89lqmyp2ry0 [2] https://issues.apache.org/jira/browse/INFRA-24678 tison <wander4...@gmail.com> 于2023年12月27日周三 19:31写道： > > Hi, > > The Distribution Guidelines[1] in ASF Incubator website wrote: > > * Artifacts show up on https://www.npmjs.com/package/apache-<project>; > version page. > * Artifacts need to be placed in > https://pypi.org/project/apache-<project>;. To comply with ASF release > and distributions please ensure the following: > > Both require an "apache-" prefix, perhaps due to emphasize the Apache > branding. But it may introduce a longy artifact name that goes against > a conventional artifact name on that platform. > > I will start a discussion on these three topics: > > 1. A brief introduction for the frequent platforms ASF podlings and > TLPs release to. > 2. How do current podlings and TLPs do? > 3. From a branding perspective, how do we protect the Apache brand? > > ## Platforms > > 1.1 DockerHub - We have the apache org; some project like Pulsar > registers the apachepulsar org. > 1.2 Maven - We host the org.apache domain name and have a nexus > repository for releasing. > 1.3 GitHub - We have the apache org. > 1.4 NPM - We don't have an official account and this platform support > org scope[2]. > 1.5 Pypi - We don't have an official account and this platform uses a > flattened view for packages. > 1.6 Crates.io - We don't have an official account and this platform > uses a flattened view for packages. The Rust/Cargo community discusses > about the flavor [3]. > 1.7 NuGet - We don't have an official account and this platform > support org account[4]. > > ## Let's go into point 2 with these platforms in details. > > For 1.1~1.3, since the ASF has official place to hold distributions, > there is few issue. > > For 1.4, below are some examples: > > * https://www.npmjs.com/package/apache-arrow > * https://www.npmjs.com/package/apache-dubbo > * https://www.npmjs.com/package/echarts > * https://www.npmjs.com/package/openwhisk > * https://www.npmjs.com/package/@apachedubbo/dubbo > * https://www.npmjs.com/package/@apachedubbo/dubbo-node > * https://www.npmjs.com/package/thrift > * https://www.npmjs.com/package/opendal > * https://www.npmjs.com/package/skywalking-client-js > * https://www.npmjs.com/package/skywalking-backend-js > > Notably, these packages with "apache-" prefix and seems related are > unofficial: > > * https://www.npmjs.com/package/apache-spark-node > * https://www.npmjs.com/package/apache-log2 > > For 1.5, below are some examples: > > * https://pypi.org/project/apache-flink/ > * https://pypi.org/project/apache-airflow-providers-apache-flink/ > * https://pypi.org/project/apache-beam/ > * https://pypi.org/project/apache-libcloud/ > * https://pypi.org/project/apache-skywalking/ > * https://pypi.org/project/apache-tvm/ > * https://pypi.org/project/avro/ > * https://pypi.org/project/datafusion/ > * https://pypi.org/project/pyarrow/ > * https://pypi.org/project/pyspark/ > > Notably, these packages with "apache-" prefix and seems related are > unofficial: > > * https://pypi.org/project/apache-analyser/ > * https://pypi.org/project/apache-manager/ > * https://pypi.org/project/apache-server/ > > For 1.6, below are some examples: > > * https://crates.io/crates/apache-avro > * https://crates.io/crates/arrow > * https://crates.io/crates/parquet > * https://crates.io/crates/skywalking > * https://crates.io/crates/opendal > > Notably, these packages with "apache-" prefix and seems related are > unofficial: > > * https://crates.io/crates/apache-rs > * https://crates.io/crates/apache_age > * https://crates.io/crates/apache-nimble-sys > > For 1.7, below are some examples: > > * https://www.nuget.org/packages/ApacheThrift > * https://www.nuget.org/packages/Apache.Avro > * https://www.nuget.org/packages/Apache.NMS > * https://www.nuget.org/packages/Apache.Arrow > * https://www.nuget.org/packages/Apache.Ignite > * https://www.nuget.org/packages/Lucene.Net > * https://www.nuget.org/packages/DotPulsar/ > > Notably, these packages with "Apache" prefix and seems related are unofficial: > > * https://www.nuget.org/packages/Apache.Thrift > > ## Now, for point 3, > > For 1.1~1.3, it's well-known and even can be verified with the > platform that only ASF project member with permission can upload > artifacts. > > For 1.4 and 1.7, if we have an official account and make it > well-known, perhaps we can get the result as 1.1~1.3. > > For 1.5 and 1.6, the platforms are against categorizing packages with > org, while for 1.6 (Crates.io), it supports add a GitHub team as a > crate owner that can be "@apache/foo-committers". > > For 1.4~1.7, there are projects with "apache" prefix but not endorsed > by an ASF project (P)PMC, the platform doesn't provide method to > forbit them. And multiple projects were published without Apache in > artifact name but have Apache brand in the metadata and README. > > Take a project Foo released to pypi as an example. Before donated to > the ASF, by no reason it would include "apache" in name or even it's a > brand occupancy issue itself. > > Now, the SGA is signed, so legally the name Foo is donated to the ASF. > As time goes on, the truth that Foo is an ASF project spread. > > Back to the technical part, if the PMC now tells its user that the > widely used name must be renamed to apache-foo, it's an extra burden > to suffer. Given that the foo brand is transferred to the ASF with > SGA, there is even no conflict to avoid. > > ## Proposal > > So, I propose to change the sentences referred above in Distribution > Guidelines[1] from a requirement tongue into a recommendation tongue. > Specificly, > > * Artifacts show up on https://www.npmjs.com/package/apache-<project>; > version page. > * Artifacts need to be placed in > https://pypi.org/project/apache-<project>;. To comply with ASF release > and distributions please ensure the following: > > Other sentences remain the same. Modifying metadata and README is cheap. > > Of course, the fact that they are "guidelines" already shows their > recommendation property. But we run the Incubator and even the ASF by > consensus. So here is the discussion for sharing thoughts. > > For 1.4 (NPM) and 1.7 (NuGet), if we later have an official > scope/account with INFRA's help, we can encourage existing projects to > migrate and gradually advocate its formality - why Maven releases > don't have such friction for its audience? Because > <group>org.apache.foo</group> is well-known and a self-claimed ASF > project outside such group is doubtable. If we do care about the > organization category, we should provide the necessary INFRA support > first. > > For 1.5 (Pypi) and 1.6 (Crates.io), their culture is anti-organization > and from some extra metadata and the README, it's not hard to figure > out if the artifacts is an ASF product. > > Looking forward to your feedback. > > Best, > tison. > > [1] https://incubator.apache.org/guides/distribution.html > [2] https://docs.npmjs.com/creating-and-publishing-scoped-public-packages > [3] https://github.com/rust-lang/cargo/issues/975 > [4] > https://learn.microsoft.com/en-us/nuget/nuget-org/organizations-on-nuget-org --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
