Re: [VOTE] Release Apache Celeborn(Incubating) 0.3.2-incubating-rc1

[Keyong Zhou]

Hi Justin,

Thanks for your input!

> There is some overlap with some files with [1]; this is concerning as
these files are under a GPL license. Would you happen to know who has
copied from whom here? If ASF files have been re-licensed under the GPL
license, what is the PMC doing about this? What is the relationship, if
any, between this company and the PMC?

We just checked their repo and found the PR[1] which added Celeborn's code
in their repo. We got in touch with them and they told us that the code was
deleted a month ago. I also checked their release[2] and didn't find
Celeborn's code in their source ball. So I guess this is no longer a
problem?

[1] https://github.com/alldatacenter/alldata/pull/415
[2] https://github.com/alldatacenter/alldata/releases

Thanks,
Keyong Zhou

Justin Mclean  于2023年12月27日周三 15:00写道：

> Hi,
>
> Sorry, but it is -1 (binding) for now. Clearing up some of the issues
> below may mean that I change my vote.
>
> I checked
> - incubating in artifact name
> - signatures and hashes are correct
> - LICENSE mentions 1 3rd party file from Guava; however, the NOTICE lists
> both Apache Spark and Apache Flink, so I think other files may have been
> copied into the code base, and LICENSE is missing information or the NOTICE
> is incorrect.
> - There is some overlap with some files with [1]; this is concerning as
> these files are under a GPL license. Would you happen to know who has
> copied from whom here? If ASF files have been re-licensed under the GPL
> license, what is the PMC doing about this? What is the relationship, if
> any, between this company and the PMC?
> - This file [2] seems to have been copied from Kyuubi?
> - No unexpected binary files
> - All files have correct source headers
> - I didn't compile from the source
>
> Kind Regards,
> Justin
>
> 1. https://github.com/alldatacenter/alldata
> 2. /dev/checkout_pr.sh
>
>

Re: [VOTE] Release Apache Pekko(incubating) Persistence R2DBC 1.0.0-RC1

[PJ Fanning]

Would any of the Pekko mentors or indeed, any Incubator PMC members have time 
to review this Pekko RC? It marks the final set of Pekko modules that have yet 
to be released.

On 2023/12/20 23:10:25 Matthew de Detrich wrote:
> Carrying over my +1 vote from
> https://lists.apache.org/thread/yyhoygwhox5yzrxy716kjmy7gcd4hm1r
> 
> On Tue, Dec 19, 2023 at 7:16 PM PJ Fanning  wrote:
> 
> > Hello Incubator Community,
> >
> > This is a call for a vote to release Apache Pekko(incubating)
> > Persistence R2DBC version 1.0.0-RC1.
> >
> > The Pekko vote result:
> > https://lists.apache.org/thread/w06swd1nd5jphtlronffw4jw18orn4hy
> >
> > Pekko Vote Thread
> > https://lists.apache.org/thread/k9xn5gyldpq0dypdo7cxgjjxkc04xtco
> >
> > The discussion thread:
> > https://lists.apache.org/thread/108tfnxofmp5bvq9y60pmwn34d6bs5s6
> >
> > The release candidate:
> >
> >
> > https://dist.apache.org/repos/dist/dev/incubator/pekko/PERSISTENCE-R2DBC-1.0.0-RC1/
> >
> > This release has been signed with a PGP key, available here:
> >
> > https://dist.apache.org/repos/dist/release/incubator/pekko/KEYS
> >
> > Git branch for the release:
> >
> > https://github.com/apache/incubator-pekko-persistence-r2dbc/tree/v1.0.0-RC1
> > Git commit ID: 3fc28f10a4570c9834495fef1d104a2dbd07fb44
> >
> > Please download, verify, and test.
> >
> > We have also staged jars in the Apache Nexus Repository. These were
> > built with the same code
> > as appears in this Source Release Candidate. We would appreciate if
> > users could test with these too.
> > If anyone finds any serious problems with these jars, please also
> > notify us on this thread.
> >
> > https://repository.apache.org/content/groups/staging/org/apache/pekko/
> >
> > In sbt, you can add this resolver.
> >
> > resolvers += "Apache Pekko Staging" at
> > "https://repository.apache.org/content/groups/staging;
> >
> >
> > The vote will be left open for at least 72 hours.
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> > To learn more about Apache Pekko, please see https://pekko.apache.org/
> >
> > Checklist for reference:
> >
> > [ ] Download links are valid.
> > [ ] Checksums and signatures.
> > [ ] LICENSE/NOTICE files exist
> > [ ] No unexpected binary files
> > [ ] Source files have ASF headers
> > [ ] Can compile from source
> >
> > To compile from the source, please refer to:
> >
> >
> > https://github.com/apache/incubator-pekko/blob/main/README.md#building-from-source
> >
> > Some of the tests rely on postgresql running locally on port 5432 and
> > the DDL is at ddl-scripts/create_tables_postgres.sql
> >
> > Some notes about verifying downloads can be found at:
> >
> > https://pekko.apache.org/download.html#verifying-downloads
> >
> >
> > Here is my +1 (binding).
> >
> > Thanks,
> >
> > PJ Fanning
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
> 
> -- 
> 
> Matthew de Detrich
> 
> *Aiven Deutschland GmbH*
> 
> Immanuelkirchstraße 26, 10405 Berlin
> 
> Alexanderufer 3-7, 10117 Berlin
> 
> Amtsgericht Charlottenburg, HRB 209739 B
> 
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> 
> *m:* +491603708037
> 
> *w:* aiven.io *e:* matthew.dedetr...@aiven.io
> 

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

[DISCUSS] Branding in Thirdparty Platform Distribution

[tison]

Hi,

The Distribution Guidelines[1] in ASF Incubator website wrote:

* Artifacts show up on https://www.npmjs.com/package/apache-;
version page.
* Artifacts need to be placed in
https://pypi.org/project/apache-;. 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 

[RESULT] [VOTE] Release Apache Pekko(incubating) Persistence R2DBC 1.0.0-RC1

[PJ Fanning]

The vote passes with 3 binding +1s.

Vote Thread
https://lists.apache.org/thread/rschhjdlqqqjhngbhgn5z8hr4jkyvvbh

Votes
Duo Zhang
Matthew de Detrich
PJ Fanning

I will proceed with the release and make the announcements over the coming days.

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

Re: [LICENSE QUESTION] Use jmh as a benchmark tool

[John D. Ament]

On Tue, Dec 26, 2023 at 8:09 PM tison  wrote:

> Hi,
>
> The new podling Fury depends on jmh[1] which is licensed under GPLv2
> with "CLASSPATH" EXCEPTION.
>

Just to confirm, are you referring to the code under [benchmark]?


>
> IIRC Flink ever factored out its benchmark code into a separate repo
> [2] to comply with ASF's license policy [3].
>

As a word of caution, don't approach things as "TLP [x] does it this way so
it must be the preferred way"


>
> But since Fury doesn't modify jmh's code, just refers to some
> "org.openjdk.jmh." classes, I wonder if it's the same that a Java
> source file refers to JDK's classes under GPLv2 with "CLASSPATH"
> EXCEPTION.
>
> Or, we can exclude the benchmark code from the release like [4] but
> still hold it in the VCS.
>

There's a difference between the GPL+CPE Cat X ruling we list on our
license website and how you're using JMH.  When it comes to a Java
application, a developer has preinstalled the JDK (or using a manager of
some kind to install it - so not something we're forcing upon them).  In
the case of JMH, the repository I linked above forces the user to download
the additional dependency from maven central (or similar repository) rather
than relying on the system preinstalled library.

It's probably worth a question to legal, but I'm inclined to believe the
answer is no, you can't use org.openjdk.jmh:* as a compile/test compile
dependency in your project but would be happy to be wrong about that.


>
> Best,
> tison.
>
> [1] https://github.com/openjdk/jmh?tab=GPL-2.0-1-ov-file
> [2] https://github.com/apache/flink-benchmarks
> [3] https://www.apache.org/legal/resolved.html
> [4] https://github.com/apache/incubator-opendal/blob/main/.gitattributes


[benchmark]:
https://github.com/apache/incubator-fury/tree/main/java/fury-benchmark


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

Re: [VOTE] Release Apache Pekko(incubating) Persistence R2DBC 1.0.0-RC1

[PJ Fanning]

Thanks Duo Zhang. I'll see about getting some build docs ready for the next RC.

I did include this in the vote email but it is definitely better to
have proper build docs.

{snip}
Some of the tests rely on postgresql running locally on port 5432 and
the DDL is at ddl-scripts/create_tables_postgres.sql
{snip}

On Wed, 27 Dec 2023 at 12:54, 张铎(Duo Zhang)  wrote:
>
> +1 binding
>
> Checked sigs and sums: Matched
> LICENSE and NOTICE: Looks fine
> DISCLAIMER: In place
> Built from src:
>   I pulled the docker image
> 'eclipse-temurin-focal-11.0.21_9_1.9.8_3.3.1' and then type sbt,
> passed
> Run tests:
>   I just typed test in the sbt shell but it failed with 'Cannot
> connect to localhost:5432', seems we need to start some external
> services while running tests but I did not find any related
> documentation about how to test
>
> Thanks.
>
> PJ Fanning  于2023年12月27日周三 18:04写道：
> >
> > Would any of the Pekko mentors or indeed, any Incubator PMC members have 
> > time to review this Pekko RC? It marks the final set of Pekko modules that 
> > have yet to be released.
> >
> > On 2023/12/20 23:10:25 Matthew de Detrich wrote:
> > > Carrying over my +1 vote from
> > > https://lists.apache.org/thread/yyhoygwhox5yzrxy716kjmy7gcd4hm1r
> > >
> > > On Tue, Dec 19, 2023 at 7:16 PM PJ Fanning  wrote:
> > >
> > > > Hello Incubator Community,
> > > >
> > > > This is a call for a vote to release Apache Pekko(incubating)
> > > > Persistence R2DBC version 1.0.0-RC1.
> > > >
> > > > The Pekko vote result:
> > > > https://lists.apache.org/thread/w06swd1nd5jphtlronffw4jw18orn4hy
> > > >
> > > > Pekko Vote Thread
> > > > https://lists.apache.org/thread/k9xn5gyldpq0dypdo7cxgjjxkc04xtco
> > > >
> > > > The discussion thread:
> > > > https://lists.apache.org/thread/108tfnxofmp5bvq9y60pmwn34d6bs5s6
> > > >
> > > > The release candidate:
> > > >
> > > >
> > > > https://dist.apache.org/repos/dist/dev/incubator/pekko/PERSISTENCE-R2DBC-1.0.0-RC1/
> > > >
> > > > This release has been signed with a PGP key, available here:
> > > >
> > > > https://dist.apache.org/repos/dist/release/incubator/pekko/KEYS
> > > >
> > > > Git branch for the release:
> > > >
> > > > https://github.com/apache/incubator-pekko-persistence-r2dbc/tree/v1.0.0-RC1
> > > > Git commit ID: 3fc28f10a4570c9834495fef1d104a2dbd07fb44
> > > >
> > > > Please download, verify, and test.
> > > >
> > > > We have also staged jars in the Apache Nexus Repository. These were
> > > > built with the same code
> > > > as appears in this Source Release Candidate. We would appreciate if
> > > > users could test with these too.
> > > > If anyone finds any serious problems with these jars, please also
> > > > notify us on this thread.
> > > >
> > > > https://repository.apache.org/content/groups/staging/org/apache/pekko/
> > > >
> > > > In sbt, you can add this resolver.
> > > >
> > > > resolvers += "Apache Pekko Staging" at
> > > > "https://repository.apache.org/content/groups/staging;
> > > >
> > > >
> > > > The vote will be left open for at least 72 hours.
> > > >
> > > > [ ] +1 approve
> > > > [ ] +0 no opinion
> > > > [ ] -1 disapprove with the reason
> > > >
> > > > To learn more about Apache Pekko, please see https://pekko.apache.org/
> > > >
> > > > Checklist for reference:
> > > >
> > > > [ ] Download links are valid.
> > > > [ ] Checksums and signatures.
> > > > [ ] LICENSE/NOTICE files exist
> > > > [ ] No unexpected binary files
> > > > [ ] Source files have ASF headers
> > > > [ ] Can compile from source
> > > >
> > > > To compile from the source, please refer to:
> > > >
> > > >
> > > > https://github.com/apache/incubator-pekko/blob/main/README.md#building-from-source
> > > >
> > > > Some of the tests rely on postgresql running locally on port 5432 and
> > > > the DDL is at ddl-scripts/create_tables_postgres.sql
> > > >
> > > > Some notes about verifying downloads can be found at:
> > > >
> > > > https://pekko.apache.org/download.html#verifying-downloads
> > > >
> > > >
> > > > Here is my +1 (binding).
> > > >
> > > > Thanks,
> > > >
> > > > PJ Fanning
> > > >
> > > > -
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >
> > > >
> > >
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > *Aiven Deutschland GmbH*
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Alexanderufer 3-7, 10117 Berlin
> > >
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >
> > > *m:* +491603708037
> > >
> > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io
> > >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> -
> To 

Re: [VOTE] Release Apache HugeGraph (Incubating) 1.2.0 rc1

[Yu Li]

Thanks for the clarification Willem and Justin, I've updated the Incubator
Release Checklist document [1] accordingly.

I hereby withdraw my -1 and below is my updated vote:

+1 (binding)

- Checked sum and signatures: OK

- Checked DISCLAIMER file exists: OK

- Checked LICENSE and NOTICE files: OK

- Checked no binary files in source package: OK

- Checked release file name and location: OK
- Checked compile from source: OK (JDK 11u21)
  * Note: hugegraph-computer requires java 11 to compile but the current
document [2] doesn't mention this (java 11 is marked as recommended but not
required), and I suggest adding some notes. The other source packages could
be compiled by java 8u101.

Best Regards,
Yu

[1]
https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist
[2]
https://hugegraph.apache.org/docs/contribution-guidelines/validate-release/


On Wed, 27 Dec 2023 at 14:33, Justin Mclean 
wrote:

> Hi,
>
> +1  (binding)
>
> I checked all source releases.
>
> - incubating in names
> - all release include LICENSE, NOTICE and DISCLAIMER
> - The NOTICE file for huge graph-computer could be improved, as it
> contains unnecessary information. "Copyright 2012 and onwards JanusGraph
> Authors” is clearly not correct.
> - The NOTICE file for the main source release duplicate information, i.e.
> "This product includes software developed at The Apache Software Foundation
> (http://www.apache.org/).” and also includes text that is not required.
> - No unexpected binary files
> - All files have correct headers, except this file might have an incorrect
> header. [1]
> - was unable to compile but probably my setup
>
> Kind Regards,
> Justin
>
> 1.
> ./hugegraph-server/hugegraph-dist/src/assembly/static/bin/wait-storage.sh
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Pekko(incubating) Persistence R2DBC 1.0.0-RC1

[Duo Zhang]

+1 binding

Checked sigs and sums: Matched
LICENSE and NOTICE: Looks fine
DISCLAIMER: In place
Built from src:
  I pulled the docker image
'eclipse-temurin-focal-11.0.21_9_1.9.8_3.3.1' and then type sbt,
passed
Run tests:
  I just typed test in the sbt shell but it failed with 'Cannot
connect to localhost:5432', seems we need to start some external
services while running tests but I did not find any related
documentation about how to test

Thanks.

PJ Fanning  于2023年12月27日周三 18:04写道：
>
> Would any of the Pekko mentors or indeed, any Incubator PMC members have time 
> to review this Pekko RC? It marks the final set of Pekko modules that have 
> yet to be released.
>
> On 2023/12/20 23:10:25 Matthew de Detrich wrote:
> > Carrying over my +1 vote from
> > https://lists.apache.org/thread/yyhoygwhox5yzrxy716kjmy7gcd4hm1r
> >
> > On Tue, Dec 19, 2023 at 7:16 PM PJ Fanning  wrote:
> >
> > > Hello Incubator Community,
> > >
> > > This is a call for a vote to release Apache Pekko(incubating)
> > > Persistence R2DBC version 1.0.0-RC1.
> > >
> > > The Pekko vote result:
> > > https://lists.apache.org/thread/w06swd1nd5jphtlronffw4jw18orn4hy
> > >
> > > Pekko Vote Thread
> > > https://lists.apache.org/thread/k9xn5gyldpq0dypdo7cxgjjxkc04xtco
> > >
> > > The discussion thread:
> > > https://lists.apache.org/thread/108tfnxofmp5bvq9y60pmwn34d6bs5s6
> > >
> > > The release candidate:
> > >
> > >
> > > https://dist.apache.org/repos/dist/dev/incubator/pekko/PERSISTENCE-R2DBC-1.0.0-RC1/
> > >
> > > This release has been signed with a PGP key, available here:
> > >
> > > https://dist.apache.org/repos/dist/release/incubator/pekko/KEYS
> > >
> > > Git branch for the release:
> > >
> > > https://github.com/apache/incubator-pekko-persistence-r2dbc/tree/v1.0.0-RC1
> > > Git commit ID: 3fc28f10a4570c9834495fef1d104a2dbd07fb44
> > >
> > > Please download, verify, and test.
> > >
> > > We have also staged jars in the Apache Nexus Repository. These were
> > > built with the same code
> > > as appears in this Source Release Candidate. We would appreciate if
> > > users could test with these too.
> > > If anyone finds any serious problems with these jars, please also
> > > notify us on this thread.
> > >
> > > https://repository.apache.org/content/groups/staging/org/apache/pekko/
> > >
> > > In sbt, you can add this resolver.
> > >
> > > resolvers += "Apache Pekko Staging" at
> > > "https://repository.apache.org/content/groups/staging;
> > >
> > >
> > > The vote will be left open for at least 72 hours.
> > >
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > > To learn more about Apache Pekko, please see https://pekko.apache.org/
> > >
> > > Checklist for reference:
> > >
> > > [ ] Download links are valid.
> > > [ ] Checksums and signatures.
> > > [ ] LICENSE/NOTICE files exist
> > > [ ] No unexpected binary files
> > > [ ] Source files have ASF headers
> > > [ ] Can compile from source
> > >
> > > To compile from the source, please refer to:
> > >
> > >
> > > https://github.com/apache/incubator-pekko/blob/main/README.md#building-from-source
> > >
> > > Some of the tests rely on postgresql running locally on port 5432 and
> > > the DDL is at ddl-scripts/create_tables_postgres.sql
> > >
> > > Some notes about verifying downloads can be found at:
> > >
> > > https://pekko.apache.org/download.html#verifying-downloads
> > >
> > >
> > > Here is my +1 (binding).
> > >
> > > Thanks,
> > >
> > > PJ Fanning
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Alexanderufer 3-7, 10117 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetr...@aiven.io
> >
>
> -
> 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: [LICENSE QUESTION] Use jmh as a benchmark tool

[John D. Ament]

On Wed, Dec 27, 2023 at 11:38 AM tison  wrote:

> > application, a developer has preinstalled the JDK (or using a manager of
> > some kind to install it - so not something we're forcing upon them).  In
>
> No. To running a Java Application in a normal way, the JRE is
> required. Saying "not something we're forcing upon them" sounds
> sophistry.
>
> Best,
> tison.
>
> tison  于2023年12月28日周四 00:27写道：
> >
> > Hi John,
> >
> > Glad to hear your feedback. Reply inline:
> >
> > > In the case of JMH, the repository I linked above forces the user to
> download
> > > the additional dependency from maven central (or similar repository)
> rather
> > > than relying on the system preinstalled library.
> >
> > From a technical view, this is not true because you can download the
> > libs manually and place them under MAVEN_HOME. Then it can be regarded
> > as a "system preinstalled library". It's the same as download JDK and
> > place them under JAVA_HOME.
>

Except that's not how these libraries are listed within your pom file.  If
there was a step where you required a developer to download these files,
what you're describing would be accurate, but they're downloaded in an
automated fashion.  Keep in mind, this isn't the JMH that's distributed
with the JDK that you're using here, it's an add-on library you're using.


> >
> > > you can't use org.openjdk.jmh:* as a compile/test compile
> > > dependency in your project
> >
> > fury-benchmark is not released in binary form. But we can of course
> > make it an optional dependency (or the entire module optionally)
> > behind a profile and deactivated by default so that it's the same as
> > how ASF projects can optionally depend on MySQL Connector Java under
> > the same license.
>

The question here isn't about binary form.  Keep in mind that first and
foremost ASF projects produce source code releases, the convenience
binaries are a separate artifact.  I'm presently approaching your thread
focused on the source code release.  I can see your point though and that's
where I'm suggesting asking legal may give you additional guidance that I
could see leading to a similar situation as Java 9 JavaScript embeddings.
Just keep in mind that you're making a module optional to compile, rather
than optional to use, even though it's only being used for testing purposes
and our expectation (even though it may differ from reality) is that we're
reviewing the contents of the source bundle that a user downloads to
compile your code, not the binary artifact they depend upon in their
projects.


> >
> > A related discussion can be found at [1].
>

Yes, and Hen's response is very appropriate to that situation.  It's not
really relevant to your situation though since the concern in this thread
is your source release, not binary release.  You can make something like
this optional, and if you keep the benchmark as optional you should be fine
as well.  For instance, if your maven build is `-Pbenchmark` and it's clear
that the user needs to include this license when compiling from source.


> >
> > >> THEY MAY BE RELIED UPON WHEN THEY SUPPORT AN OPTIONAL FEATURE
> > >> "Will the majority of users want to use my product without adding the
> optional components?"
> >
> > No. Benchmark is for testing; most users don't even know it and cannot
> > depend on it as a Maven artifact.

>
> > P.S.
> > > don't approach things as "TLP [x] does it this way so
> > > it must be the preferred way"
> > Yeah .. Even I don't think Flink did it correctly, this expression
> > increases confusion. Most readers don't have the context to understand
> > the referred case. I'll avoid it.
> >
> > Best,
> > tison.
> >
> > [1] https://issues.apache.org/jira/browse/LEGAL-437
> >
> > John D. Ament  于2023年12月27日周三 23:57写道：
> > >
> > > On Tue, Dec 26, 2023 at 8:09 PM tison  wrote:
> > >
> > > > Hi,
> > > >
> > > > The new podling Fury depends on jmh[1] which is licensed under GPLv2
> > > > with "CLASSPATH" EXCEPTION.
> > > >
> > >
> > > Just to confirm, are you referring to the code under [benchmark]?
> > >
> > >
> > > >
> > > > IIRC Flink ever factored out its benchmark code into a separate repo
> > > > [2] to comply with ASF's license policy [3].
> > > >
> > >
> > > As a word of caution, don't approach things as "TLP [x] does it this
> way so
> > > it must be the preferred way"
> > >
> > >
> > > >
> > > > But since Fury doesn't modify jmh's code, just refers to some
> > > > "org.openjdk.jmh." classes, I wonder if it's the same that a Java
> > > > source file refers to JDK's classes under GPLv2 with "CLASSPATH"
> > > > EXCEPTION.
> > > >
> > > > Or, we can exclude the benchmark code from the release like [4] but
> > > > still hold it in the VCS.
> > > >
> > >
> > > There's a difference between the GPL+CPE Cat X ruling we list on our
> > > license website and how you're using JMH.  When it comes to a Java
> > > application, a developer has preinstalled the JDK (or using a manager
> of
> > > some kind to install it - so not 

Re: [LICENSE QUESTION] Use jmh as a benchmark tool

[tison]

> For instance, if your maven build is `-Pbenchmark` and it's clear
> that the user needs to include this license when compiling from source.

Yeah. I'm going to collaborate with Fury to follow this approach and
document clearly how a developer can intentionally run benchmark with
JMH as a dep.

Best,
tison.

John D. Ament  于2023年12月28日周四 01:07写道：
>
> On Wed, Dec 27, 2023 at 11:38 AM tison  wrote:
>
> > > application, a developer has preinstalled the JDK (or using a manager of
> > > some kind to install it - so not something we're forcing upon them).  In
> >
> > No. To running a Java Application in a normal way, the JRE is
> > required. Saying "not something we're forcing upon them" sounds
> > sophistry.
> >
> > Best,
> > tison.
> >
> > tison  于2023年12月28日周四 00:27写道：
> > >
> > > Hi John,
> > >
> > > Glad to hear your feedback. Reply inline:
> > >
> > > > In the case of JMH, the repository I linked above forces the user to
> > download
> > > > the additional dependency from maven central (or similar repository)
> > rather
> > > > than relying on the system preinstalled library.
> > >
> > > From a technical view, this is not true because you can download the
> > > libs manually and place them under MAVEN_HOME. Then it can be regarded
> > > as a "system preinstalled library". It's the same as download JDK and
> > > place them under JAVA_HOME.
> >
>
> Except that's not how these libraries are listed within your pom file.  If
> there was a step where you required a developer to download these files,
> what you're describing would be accurate, but they're downloaded in an
> automated fashion.  Keep in mind, this isn't the JMH that's distributed
> with the JDK that you're using here, it's an add-on library you're using.
>
>
> > >
> > > > you can't use org.openjdk.jmh:* as a compile/test compile
> > > > dependency in your project
> > >
> > > fury-benchmark is not released in binary form. But we can of course
> > > make it an optional dependency (or the entire module optionally)
> > > behind a profile and deactivated by default so that it's the same as
> > > how ASF projects can optionally depend on MySQL Connector Java under
> > > the same license.
> >
>
> The question here isn't about binary form.  Keep in mind that first and
> foremost ASF projects produce source code releases, the convenience
> binaries are a separate artifact.  I'm presently approaching your thread
> focused on the source code release.  I can see your point though and that's
> where I'm suggesting asking legal may give you additional guidance that I
> could see leading to a similar situation as Java 9 JavaScript embeddings.
> Just keep in mind that you're making a module optional to compile, rather
> than optional to use, even though it's only being used for testing purposes
> and our expectation (even though it may differ from reality) is that we're
> reviewing the contents of the source bundle that a user downloads to
> compile your code, not the binary artifact they depend upon in their
> projects.
>
>
> > >
> > > A related discussion can be found at [1].
> >
>
> Yes, and Hen's response is very appropriate to that situation.  It's not
> really relevant to your situation though since the concern in this thread
> is your source release, not binary release.  You can make something like
> this optional, and if you keep the benchmark as optional you should be fine
> as well.  For instance, if your maven build is `-Pbenchmark` and it's clear
> that the user needs to include this license when compiling from source.
>
>
> > >
> > > >> THEY MAY BE RELIED UPON WHEN THEY SUPPORT AN OPTIONAL FEATURE
> > > >> "Will the majority of users want to use my product without adding the
> > optional components?"
> > >
> > > No. Benchmark is for testing; most users don't even know it and cannot
> > > depend on it as a Maven artifact.
>
> >
> > > P.S.
> > > > don't approach things as "TLP [x] does it this way so
> > > > it must be the preferred way"
> > > Yeah .. Even I don't think Flink did it correctly, this expression
> > > increases confusion. Most readers don't have the context to understand
> > > the referred case. I'll avoid it.
> > >
> > > Best,
> > > tison.
> > >
> > > [1] https://issues.apache.org/jira/browse/LEGAL-437
> > >
> > > John D. Ament  于2023年12月27日周三 23:57写道：
> > > >
> > > > On Tue, Dec 26, 2023 at 8:09 PM tison  wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > The new podling Fury depends on jmh[1] which is licensed under GPLv2
> > > > > with "CLASSPATH" EXCEPTION.
> > > > >
> > > >
> > > > Just to confirm, are you referring to the code under [benchmark]?
> > > >
> > > >
> > > > >
> > > > > IIRC Flink ever factored out its benchmark code into a separate repo
> > > > > [2] to comply with ASF's license policy [3].
> > > > >
> > > >
> > > > As a word of caution, don't approach things as "TLP [x] does it this
> > way so
> > > > it must be the preferred way"
> > > >
> > > >
> > > > >
> > > > > But since Fury doesn't modify jmh's code, just refers 

Re: [DISCUSS] Branding in Thirdparty Platform Distribution

[tison]

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  于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-;
> version page.
> * Artifacts need to be placed in
> https://pypi.org/project/apache-;. 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 

Re: [VOTE] Release Apache Celeborn(Incubating) 0.3.2-incubating-rc1

[Justin Mclean]

Hi,

> We just checked their repo and found the PR[1] which added Celeborn's code
> in their repo. We got in touch with them and they told us that the code was
> deleted a month ago. I also checked their release[2] and didn't find
> Celeborn's code in their source ball. So I guess this is no longer a
> problem?

Thanks for looking into that; that looks to be a non-issue. Can anyone answer 
my other questions?

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

Re: [LICENSE QUESTION] Use jmh as a benchmark tool

[tison]

Hi John,

Glad to hear your feedback. Reply inline:

> In the case of JMH, the repository I linked above forces the user to download
> the additional dependency from maven central (or similar repository) rather
> than relying on the system preinstalled library.

>From a technical view, this is not true because you can download the
libs manually and place them under MAVEN_HOME. Then it can be regarded
as a "system preinstalled library". It's the same as download JDK and
place them under JAVA_HOME.

> you can't use org.openjdk.jmh:* as a compile/test compile
> dependency in your project

fury-benchmark is not released in binary form. But we can of course
make it an optional dependency (or the entire module optionally)
behind a profile and deactivated by default so that it's the same as
how ASF projects can optionally depend on MySQL Connector Java under
the same license.

A related discussion can be found at [1].

>> THEY MAY BE RELIED UPON WHEN THEY SUPPORT AN OPTIONAL FEATURE
>> "Will the majority of users want to use my product without adding the 
>> optional components?"

No. Benchmark is for testing; most users don't even know it and cannot
depend on it as a Maven artifact.

P.S.
> don't approach things as "TLP [x] does it this way so
> it must be the preferred way"
Yeah .. Even I don't think Flink did it correctly, this expression
increases confusion. Most readers don't have the context to understand
the referred case. I'll avoid it.

Best,
tison.

[1] https://issues.apache.org/jira/browse/LEGAL-437

John D. Ament  于2023年12月27日周三 23:57写道：
>
> On Tue, Dec 26, 2023 at 8:09 PM tison  wrote:
>
> > Hi,
> >
> > The new podling Fury depends on jmh[1] which is licensed under GPLv2
> > with "CLASSPATH" EXCEPTION.
> >
>
> Just to confirm, are you referring to the code under [benchmark]?
>
>
> >
> > IIRC Flink ever factored out its benchmark code into a separate repo
> > [2] to comply with ASF's license policy [3].
> >
>
> As a word of caution, don't approach things as "TLP [x] does it this way so
> it must be the preferred way"
>
>
> >
> > But since Fury doesn't modify jmh's code, just refers to some
> > "org.openjdk.jmh." classes, I wonder if it's the same that a Java
> > source file refers to JDK's classes under GPLv2 with "CLASSPATH"
> > EXCEPTION.
> >
> > Or, we can exclude the benchmark code from the release like [4] but
> > still hold it in the VCS.
> >
>
> There's a difference between the GPL+CPE Cat X ruling we list on our
> license website and how you're using JMH.  When it comes to a Java
> application, a developer has preinstalled the JDK (or using a manager of
> some kind to install it - so not something we're forcing upon them).  In
> the case of JMH, the repository I linked above forces the user to download
> the additional dependency from maven central (or similar repository) rather
> than relying on the system preinstalled library.
>
> It's probably worth a question to legal, but I'm inclined to believe the
> answer is no, you can't use org.openjdk.jmh:* as a compile/test compile
> dependency in your project but would be happy to be wrong about that.
>
>
> >
> > Best,
> > tison.
> >
> > [1] https://github.com/openjdk/jmh?tab=GPL-2.0-1-ov-file
> > [2] https://github.com/apache/flink-benchmarks
> > [3] https://www.apache.org/legal/resolved.html
> > [4] https://github.com/apache/incubator-opendal/blob/main/.gitattributes
>
>
> [benchmark]:
> https://github.com/apache/incubator-fury/tree/main/java/fury-benchmark
>
>
> >
> >
> > -
> > 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: [LICENSE QUESTION] Use jmh as a benchmark tool

[tison]

> application, a developer has preinstalled the JDK (or using a manager of
> some kind to install it - so not something we're forcing upon them).  In

No. To running a Java Application in a normal way, the JRE is
required. Saying "not something we're forcing upon them" sounds
sophistry.

Best,
tison.

tison  于2023年12月28日周四 00:27写道：
>
> Hi John,
>
> Glad to hear your feedback. Reply inline:
>
> > In the case of JMH, the repository I linked above forces the user to 
> > download
> > the additional dependency from maven central (or similar repository) rather
> > than relying on the system preinstalled library.
>
> From a technical view, this is not true because you can download the
> libs manually and place them under MAVEN_HOME. Then it can be regarded
> as a "system preinstalled library". It's the same as download JDK and
> place them under JAVA_HOME.
>
> > you can't use org.openjdk.jmh:* as a compile/test compile
> > dependency in your project
>
> fury-benchmark is not released in binary form. But we can of course
> make it an optional dependency (or the entire module optionally)
> behind a profile and deactivated by default so that it's the same as
> how ASF projects can optionally depend on MySQL Connector Java under
> the same license.
>
> A related discussion can be found at [1].
>
> >> THEY MAY BE RELIED UPON WHEN THEY SUPPORT AN OPTIONAL FEATURE
> >> "Will the majority of users want to use my product without adding the 
> >> optional components?"
>
> No. Benchmark is for testing; most users don't even know it and cannot
> depend on it as a Maven artifact.
>
> P.S.
> > don't approach things as "TLP [x] does it this way so
> > it must be the preferred way"
> Yeah .. Even I don't think Flink did it correctly, this expression
> increases confusion. Most readers don't have the context to understand
> the referred case. I'll avoid it.
>
> Best,
> tison.
>
> [1] https://issues.apache.org/jira/browse/LEGAL-437
>
> John D. Ament  于2023年12月27日周三 23:57写道：
> >
> > On Tue, Dec 26, 2023 at 8:09 PM tison  wrote:
> >
> > > Hi,
> > >
> > > The new podling Fury depends on jmh[1] which is licensed under GPLv2
> > > with "CLASSPATH" EXCEPTION.
> > >
> >
> > Just to confirm, are you referring to the code under [benchmark]?
> >
> >
> > >
> > > IIRC Flink ever factored out its benchmark code into a separate repo
> > > [2] to comply with ASF's license policy [3].
> > >
> >
> > As a word of caution, don't approach things as "TLP [x] does it this way so
> > it must be the preferred way"
> >
> >
> > >
> > > But since Fury doesn't modify jmh's code, just refers to some
> > > "org.openjdk.jmh." classes, I wonder if it's the same that a Java
> > > source file refers to JDK's classes under GPLv2 with "CLASSPATH"
> > > EXCEPTION.
> > >
> > > Or, we can exclude the benchmark code from the release like [4] but
> > > still hold it in the VCS.
> > >
> >
> > There's a difference between the GPL+CPE Cat X ruling we list on our
> > license website and how you're using JMH.  When it comes to a Java
> > application, a developer has preinstalled the JDK (or using a manager of
> > some kind to install it - so not something we're forcing upon them).  In
> > the case of JMH, the repository I linked above forces the user to download
> > the additional dependency from maven central (or similar repository) rather
> > than relying on the system preinstalled library.
> >
> > It's probably worth a question to legal, but I'm inclined to believe the
> > answer is no, you can't use org.openjdk.jmh:* as a compile/test compile
> > dependency in your project but would be happy to be wrong about that.
> >
> >
> > >
> > > Best,
> > > tison.
> > >
> > > [1] https://github.com/openjdk/jmh?tab=GPL-2.0-1-ov-file
> > > [2] https://github.com/apache/flink-benchmarks
> > > [3] https://www.apache.org/legal/resolved.html
> > > [4] https://github.com/apache/incubator-opendal/blob/main/.gitattributes
> >
> >
> > [benchmark]:
> > https://github.com/apache/incubator-fury/tree/main/java/fury-benchmark
> >
> >
> > >
> > >
> > > -
> > > 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] Branding in Thirdparty Platform Distribution

[Justin Mclean]

Hi,

I’ll note these guidelines were discussed and voted on by the IPMC a while 
back. Legal and trademarks also reviewed them and had input, and the work is 
based on existing policy and years of discussion. They, however, have only had 
minor updates since being formed.

Kind Regards,
Justin


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

Re: [DISCUSS] Branding in Thirdparty Platform Distribution

[Justin Mclean]

Hi,

> The proposal here is to improve the expression on NPM / PyPI for the
> package name to be either:
> 
> 1. apache-projectname
> 2. projectname

Existing ASF policy has this to say:
- "All PMCs must to comply with the Apache Project Branding Requirements.” [1]
- “PMCs are directly responsible for ensuring all of their project's web 
content complies with the Apache Project Branding Requirements.” [2]
- "PMCs are responsible for evaluating and if needed addressing any infringing 
use of their project's marks by third parties” [3]

In regards to naming:
- "All top level projects (TLPs) must use the format Apache Foo for their 
branding” [4]
- "The primary branding for any project or product name must be in the form of 
"Apache Projectname”. " [5]
- "The first and most prominent references to a project or product on every 
page, and uses in page titles or headers, must use the "Apache Projectname" 
form of the name. “ [5]

This is one reason why every single poding report asks, “Is the PPMC managing 
the podling's brand / trademarks?”.

In short, IMO, using the short name would not be in line with current policy, 
but that is probably more of a question for trademarks. For instance, it might 
be OK if the page made it very clear that this was an ASF project and the users 
were downloading “Apache Foo” and included appropriate trademark attribution.

Kind Regards,
Justin

1. https://www.apache.org/foundation/marks/responsibility#compliance
2. https://www.apache.org/foundation/marks/responsibility.html#website
3. https://www.apache.org/foundation/marks/responsibility.html#police
4. https://www.apache.org/foundation/marks/pmcs#naming
5. https://www.apache.org/foundation/marks/pmcs#branding



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

[VOTE] Release Apache OpenDAL(incubating) 0.44.0-rc.1 - Incubator Vote Round 1

[Liuqing Yue]

Hello Incubator PMC,

The Apache OpenDAL community has voted and approved the release of Apache
OpenDAL(incubating) 0.44.0-rc.1. We now kindly request the IPMC members
review and vote for this release.

OpenDAL is a data access layer that allows users to easily and efficiently
retrieve data from various storage services in a unified way.

OpenDAL community vote thread:

https://lists.apache.org/thread/nycyfc1m6819bj8vsb20vmbnlhs0kbdn

Vote result thread:

https://lists.apache.org/thread/pfnlmn9vqn1rqdy54wzm3mkx1wnt9mv6

The release candidate:

https://dist.apache.org/repos/dist/dev/incubator/opendal/0.44.0-rc.1/

This release has been signed with a PGP available here:

https://downloads.apache.org/incubator/opendal/KEYS

Git tag for the release:

https://github.com/apache/incubator-opendal/releases/tag/v0.44.0-rc.1

Maven staging repo:

https://repository.apache.org/content/repositories/orgapacheopendal-1022/

Please download, verify, and test.

The VOTE will be open for at least 72 hours and until the necessary
number of votes are reached.

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

To learn more about apache opendal, please see https://opendal.apache.org/

Checklist for reference:

[ ] Download links are valid.
[ ] Checksums and signatures.
[ ] LICENSE/NOTICE files exist
[ ] No unexpected binary files
[ ] All source files have ASF headers
[ ] Can compile from source

More detailed checklist please refer to:
https://github.com/apache/incubator-opendal/tree/main/scripts

To compile from source, please refer to:
https://github.com/apache/incubator-opendal/blob/main/CONTRIBUTING.md

Here is python script in release to help you verify the release candidate:

./scripts/verify.py

Thanks

Liuqing Yue

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

Re: [VOTE] Release Apache Celeborn(Incubating) 0.3.2-incubating-rc1

[Cheng Pan]

Hi Justin

> - LICENSE mentions 1 3rd party file from Guava; however, the NOTICE lists 
> both Apache Spark and Apache Flink, so I think other files may have been 
> copied into the code base, and LICENSE is missing information or the NOTICE 
> is incorrect.

> - This file [2] seems to have been copied from Kyuubi?

We have opened CELEBORN-1202[1] to address these issues, would be great if you 
could take a look at [2].

[1] https://issues.apache.org/jira/browse/CELEBORN-1202
[2] https://github.com/apache/incubator-celeborn/pull/2193

Thanks,
Cheng Pan


> On Dec 28, 2023, at 06:07, Justin Mclean  wrote:
> 
> Hi,
> 
>> We just checked their repo and found the PR[1] which added Celeborn's code
>> in their repo. We got in touch with them and they told us that the code was
>> deleted a month ago. I also checked their release[2] and didn't find
>> Celeborn's code in their source ball. So I guess this is no longer a
>> problem?
> 
> Thanks for looking into that; that looks to be a non-issue. Can anyone answer 
> my other questions?
> 
> Kind Regards,
> 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: [DISCUSS] Gluten proposal

[ShaoFeng Shi]

Hi Rakesh,

Yeah, the team aware that, they plan to merge the Trino plugin into the
main repository at some point of time, depends on its maturity. The Hive
plugin is not on current roadmap I think, but this is open for discussion.

Best regards,

Shaofeng Shi 史少锋
Apache Kylin PMC,
Apache Incubator PMC,
Email: shaofeng...@apache.org

Apache Kylin FAQ: https://kylin.apache.org/docs/gettingstarted/faq.html
Join Kylin user mail group: user-subscr...@kylin.apache.org
Join Kylin dev mail group: dev-subscr...@kylin.apache.org




Rakesh Radhakrishnan  于2023年12月27日周三 14:06写道：

> OK, that's really interesting. I hope you will add  "Gluten-Trino
> " and "Gluten-Flink" as
> sub-projects(plugin module) under the main Gluten project and follow a
> single release cycle?
>
> Is it technically/architecturally feasible to develop a "Gluten-Hive"
> plugin (as we know Hive uses Apache Tez DAG) as a long term plan ?
>
> Thanks,
> Rakesh
>
> On Tue, Dec 26, 2023 at 4:30 PM ShaoFeng Shi 
> wrote:
>
> > Hi Rakesh,
> >
> > Thanks for your comment. The Trino plugin is under PoC, not ready for
> > widely use at this moment, so it is staged in another git repository:
> > https://github.com/oap-project/Gluten-Trino
> > Flink support is still in early discussion stage, need more collaboration
> > in the future.
> >
> > Best regards,
> >
> > Shaofeng Shi 史少锋
> > Apache Kylin PMC,
> > Apache Incubator PMC,
> > Email: shaofeng...@apache.org
> >
> > Apache Kylin FAQ: https://kylin.apache.org/docs/gettingstarted/faq.html
> > Join Kylin user mail group: user-subscr...@kylin.apache.org
> > Join Kylin dev mail group: dev-subscr...@kylin.apache.org
> >
> >
> >
> >
> > Rakesh Radhakrishnan  于2023年12月26日周二 11:24写道：
> >
> > > Thanks Shaofeng and team for the efforts!
> > >
> > > Its really interesting to see that Flink and Trino projects can get the
> > > benefits of Gluten and boost their performance. Much appreciated, if
> you
> > > could share more on this integration, perf_numbers,
> > pullrequest_reference,
> > > jira_reference etc. Will Flink and Trino already have a plugin
> mechanism
> > in
> > > place to seamlessly integrate with Gluten ?
> > >
> > > Thanks,
> > > Rakesh
> > >
> > > On Sat, Dec 23, 2023 at 6:13 PM ShaoFeng Shi 
> > > wrote:
> > >
> > > > Hi Enrico,
> > > >
> > > > This is a good question. Actually I asked the same to the team when
> > they
> > > > find me for coaching.
> > > >
> > > > As the proposal mentioned, Gluten is a middle layer between the
> > JVM-based
> > > > SQL engine and native libraries. It connects the two sides, and build
> > > > common services like unified plan transformation, seamless native
> > > > integration, clear JNI interfaces, etc. Spark is the first engine it
> > > > supports now, but the framework and mechanism can also work for other
> > > > engines like Trino, Flink SQL in the future (the proposal also
> > mentioned
> > > > this). Underlying Gluten, it can integrate with different libararies,
> > > like
> > > > Velox, Clickhouse and Arrow (not ready yet). So, its mission and
> scope
> > is
> > > > different, that's why we put it as a new project.
> > > >
> > > > Best regards,
> > > >
> > > > Shaofeng Shi 史少锋
> > > > Apache Kylin PMC,
> > > > Apache Incubator PMC,
> > > > Email: shaofeng...@apache.org
> > > >
> > > > Apache Kylin FAQ:
> > https://kylin.apache.org/docs/gettingstarted/faq.html
> > > > Join Kylin user mail group: user-subscr...@kylin.apache.org
> > > > Join Kylin dev mail group: dev-subscr...@kylin.apache.org
> > > >
> > > >
> > > >
> > > >
> > > > Enrico Olivelli  于2023年12月22日周五 22:43写道：
> > > >
> > > > > Shaofeng,
> > > > >
> > > > > Il giorno ven 22 dic 2023 alle ore 13:59 ShaoFeng Shi
> > > > >  ha scritto:
> > > > > >
> > > > > > Hi IPMC members,
> > > > > >
> > > > > > I would like to propose a new project to the ASF incubator -
> > Gluten.
> > > > > >
> > > > > > Gluten[1] is a middle layer responsible for offloading Apache
> Spark
> > > SQL
> > > > > > queries to native engines. This project aims to address the CPU
> > > > > > computational bottleneck to offload SparkSQL operators to native
> > > > engines
> > > > > in
> > > > > > data loading scenarios based on Apache Spark.
> > > > >
> > > > > Have you considered making this project a subproject of Apache
> Spark
> > ?
> > > > >
> > > > > Enrico
> > > > >
> > > > > >
> > > > > > Here is the proposal -
> > > > > >
> > https://cwiki.apache.org/confluence/display/INCUBATOR/GlutenProposal
> > > > > >
> > > > > > I would be the Champion of the project. I will mentor and help
> the
> > > > > project
> > > > > > through the incubator with Yu Li [l...@apache.org], Kent Yao [
> > > > > y...@apache.org]
> > > > > > and Wenli Zhang [ovi...@apache.org] .
> > > > > >
> > > > > > We are open to hearing the feedback from the incubator.
> > > > > >
> > > > > > Best,
> > > > > > Shaofeng Shi.
> > > > > >
> > > > > > [1] https://oap-project.github.io/gluten/
> > > > > >
> > > > > > Best 

Re: [DISCUSS] Gluten proposal

[ShaoFeng Shi]

Hi Justin,

Yeah, 12 months is a little tough; I have discussed this with the team, and
updated the proposal to 18 months.

Best regards,

Shaofeng Shi 史少锋
Apache Kylin PMC,
Apache Incubator PMC,
Email: shaofeng...@apache.org

Apache Kylin FAQ: https://kylin.apache.org/docs/gettingstarted/faq.html
Join Kylin user mail group: user-subscr...@kylin.apache.org
Join Kylin dev mail group: dev-subscr...@kylin.apache.org




Justin Mclean  于2023年12月27日周三 13:53写道：

> Hi,
>
> Looks like a good proposal. Only one thing stood out to me, while not
> impossible, planning to graduate in a year might not be easily achievable.
>
> Kind Regards,
> Justn
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Graduate Apache OpenDAL (incubating) as a TLP - Incubator

[Justin Mclean]

Hi,

> Thanks for your reply to report potential branding issues. The PMC is
> actively responding to these comments.
> 
> * https://github.com/apache/incubator-opendal/pull/3829/files
> * https://github.com/apache/incubator-opendal/pull/3830/files
> * https://github.com/apache/incubator-opendal/pull/3831/files
> * https://github.com/apache/incubator-opendal/pull/3833/files
> * https://github.com/apache/incubator-opendal/pull/3838/files

Thanks for that.

> For third-party references, when a PMC member notices one that can be
> confusing, there is a reaction:
> 
> * https://github.com/GreptimeTeam/greptimedb/pull/2653/files
> * https://github.com/zwpaper/dilu/pull/1/files
> * https://github.com/datafuselabs/databend-docs/pull/285/files

I noticed the domain opendal.databend.rs mentioned there. Who owns that domain?

> These are instances for "manage its brand and ASF’s trademarks". I
> believe that the PMC becomes more experienced on branding topics with
> your reports; thank you.

The point is I shouldn't have to report these; the (P)PMC should be managing 
this on their own.

>>> About the https://opendal.apache.org/docs/python/opendal.html,
>>> Please see https://incubator.apache.org/guides/distribution.html.
> 
> The first sentence of this page currently is "Apache OpenDAL™ Python binding".

But the first and more prominent mention of OpenDAL doesn’t include Apache. The 
page is also missing mention of ASF’s trademarks. I think you need a little 
more branding and naming is needed to comply with ASF's policy.

Other pages I click on have no mention of Apache. e.g. 
https://opendal.apache.org/docs/python/opendal/layers.html Other document pages 
have similar issues, e.g. https://opendal.apache.org/docs/haskell/OpenDAL.html. 
I think a little more work needs to be done here, and again, I shouldn't have 
to point out the issues. Please look at your documentation and the policy and 
see what needs to be fixed, or better still, discuss it on your mailing list. 
It’s far better that you work out what needs to be corrected on your own than 
for someone outside your project to list what might not be in line with policy.

> As for the package name, I argued for the current guidelines in [1]
> that you can follow. You may have different opinions and that's OK.
> Xuanwo explained more technical details and community feedback in [1].

Other projects have different reasons for doing what they do; don’t confuse 
that with permission to do what they do without a reason.

Kind Regards,
Justin

Re: [DISCUSS] Branding in Thirdparty Platform Distribution

[Xuanwo]

For the platforms npm, PyPI, crates.io, and NuGet, the situation is somewhat 
different: We deliver libraries instead binaries.

Users should run `npm install xxx`, `pip install xxx`, or `cargo add xxx` 
to include our library in their dependency list. Users should write code 
in their own libraries or applications using statements such as `use xxx` 
or `import xxx`. Adding the prefixes `apache-` or `asf-` could significantly
increase the workload for the entire community. In severe cases, users may 
halt library updates to prevent having to replace `xxx` throughout their code.

The good news is that all of these platforms offer comprehensive metadata, 
such as README files, Homepage, repositories, and signatures, which help 
determine whether the artifacts are ASF products.

On Wed, Dec 27, 2023, at 19:31, tison wrote:
> Hi,
>
> The Distribution Guidelines[1] in ASF Incubator website wrote:
>
> * Artifacts show up on https://www.npmjs.com/package/apache-;
> version page.
> * Artifacts need to be placed in
> https://pypi.org/project/apache-;. 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 

Re: [DISCUSS] Gluten proposal

[ShaoFeng Shi]

Hi Junping,

Thank you for the suggestion. I have discussed this with the team, they
agree with this. I have updated abstract part of the proposal. The slogan
on the document website will be updated later.

Best regards,

Shaofeng Shi 史少锋
Apache Kylin PMC,
Apache Incubator PMC,
Email: shaofeng...@apache.org

Apache Kylin FAQ: https://kylin.apache.org/docs/gettingstarted/faq.html
Join Kylin user mail group: user-subscr...@kylin.apache.org
Join Kylin dev mail group: dev-subscr...@kylin.apache.org




俊平堵  于2023年12月27日周三 13:46写道：

> This is definitely an interesting project and I noticed this project from
> a very early stage.
> I saw many discussions above on if Gluten should be a subproject of Spark
> or not, and I can see the value to keep it independent just like Shaofeng's
> previous points. However, the project name or slogan - "Gluten: Plugin to
> Double SparkSQL's Performance" could be updated a bit later to get rid of
> the confusion to serve SparkSQL only.
> +1 on the project going to apache. I am interested in helping as mentor if
> needed.
>
>
> Thanks,
>
> JP
>
> ShaoFeng Shi  于2023年12月22日周五 20:59写道：
>
> > Hi IPMC members,
> >
> > I would like to propose a new project to the ASF incubator - Gluten.
> >
> > Gluten[1] is a middle layer responsible for offloading Apache Spark SQL
> > queries to native engines. This project aims to address the CPU
> > computational bottleneck to offload SparkSQL operators to native engines
> in
> > data loading scenarios based on Apache Spark.
> >
> > Here is the proposal -
> > https://cwiki.apache.org/confluence/display/INCUBATOR/GlutenProposal
> >
> > I would be the Champion of the project. I will mentor and help the
> project
> > through the incubator with Yu Li [l...@apache.org], Kent Yao [
> > y...@apache.org]
> > and Wenli Zhang [ovi...@apache.org] .
> >
> > We are open to hearing the feedback from the incubator.
> >
> > Best,
> > Shaofeng Shi.
> >
> > [1] https://oap-project.github.io/gluten/
> >
> > Best regards,
> >
> > Shaofeng Shi 史少锋
> > Apache Kylin PMC,
> > Apache Incubator PMC,
> > Email: shaofeng...@apache.org
> >
> > Apache Kylin FAQ: https://kylin.apache.org/docs/gettingstarted/faq.html
> > Join Kylin user mail group: user-subscr...@kylin.apache.org
> > Join Kylin dev mail group: dev-subscr...@kylin.apache.org
> >
>

Re: [DISCUSS] Gluten proposal

[Kent Yao]

+1

We have been using Glutin with Apache Kyuubi and Apache Spark 
at NetEase for about a year now. It's a promising project.

And I'm glad to be one of the nominated mentors.

Thanks,
Kent Yao

On 2023/12/28 03:25:56 ShaoFeng Shi wrote:
> Hi Justin,
> 
> Yeah, 12 months is a little tough; I have discussed this with the team, and
> updated the proposal to 18 months.
> 
> Best regards,
> 
> Shaofeng Shi 史少锋
> Apache Kylin PMC,
> Apache Incubator PMC,
> Email: shaofeng...@apache.org
> 
> Apache Kylin FAQ: https://kylin.apache.org/docs/gettingstarted/faq.html
> Join Kylin user mail group: user-subscr...@kylin.apache.org
> Join Kylin dev mail group: dev-subscr...@kylin.apache.org
> 
> 
> 
> 
> Justin Mclean  于2023年12月27日周三 13:53写道：
> 
> > Hi,
> >
> > Looks like a good proposal. Only one thing stood out to me, while not
> > impossible, planning to graduate in a year might not be easily achievable.
> >
> > Kind Regards,
> > Justn
> > -
> > 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] Release Apache OpenDAL(incubating) 0.44.0-rc.1 - Incubator Vote Round 1

[Xuanwo]

Carry my non-binding +1 VOTE from the dev@o.a.o

On Thu, Dec 28, 2023, at 13:12, Liuqing Yue wrote:
> Hello Incubator PMC,
>
> The Apache OpenDAL community has voted and approved the release of Apache
> OpenDAL(incubating) 0.44.0-rc.1. We now kindly request the IPMC members
> review and vote for this release.
>
> OpenDAL is a data access layer that allows users to easily and efficiently
> retrieve data from various storage services in a unified way.
>
> OpenDAL community vote thread:
>
> https://lists.apache.org/thread/nycyfc1m6819bj8vsb20vmbnlhs0kbdn
>
> Vote result thread:
>
> https://lists.apache.org/thread/pfnlmn9vqn1rqdy54wzm3mkx1wnt9mv6
>
> The release candidate:
>
> https://dist.apache.org/repos/dist/dev/incubator/opendal/0.44.0-rc.1/
>
> This release has been signed with a PGP available here:
>
> https://downloads.apache.org/incubator/opendal/KEYS
>
> Git tag for the release:
>
> https://github.com/apache/incubator-opendal/releases/tag/v0.44.0-rc.1
>
> Maven staging repo:
>
> https://repository.apache.org/content/repositories/orgapacheopendal-1022/
>
> Please download, verify, and test.
>
> The VOTE will be open for at least 72 hours and until the necessary
> number of votes are reached.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> To learn more about apache opendal, please see https://opendal.apache.org/
>
> Checklist for reference:
>
> [ ] Download links are valid.
> [ ] Checksums and signatures.
> [ ] LICENSE/NOTICE files exist
> [ ] No unexpected binary files
> [ ] All source files have ASF headers
> [ ] Can compile from source
>
> More detailed checklist please refer to:
> https://github.com/apache/incubator-opendal/tree/main/scripts
>
> To compile from source, please refer to:
> https://github.com/apache/incubator-opendal/blob/main/CONTRIBUTING.md
>
> Here is python script in release to help you verify the release candidate:
>
> ./scripts/verify.py
>
> Thanks
>
> Liuqing Yue
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org

-- 
Xuanwo

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

Re: [DISCUSS] Graduate Apache OpenDAL (incubating) as a TLP - Incubator

[tison]

Hi Justin,

Thanks for your reply to report potential branding issues. The PMC is
actively responding to these comments.

* https://github.com/apache/incubator-opendal/pull/3829/files
* https://github.com/apache/incubator-opendal/pull/3830/files
* https://github.com/apache/incubator-opendal/pull/3831/files
* https://github.com/apache/incubator-opendal/pull/3833/files
* https://github.com/apache/incubator-opendal/pull/3838/files

For third-party references, when a PMC member notices one that can be
confusing, there is a reaction:

* https://github.com/GreptimeTeam/greptimedb/pull/2653/files
* https://github.com/zwpaper/dilu/pull/1/files
* https://github.com/datafuselabs/databend-docs/pull/285/files

These are instances for "manage its brand and ASF’s trademarks". I
believe that the PMC becomes more experienced on branding topics with
your reports; thank you.

>> About the https://opendal.apache.org/docs/python/opendal.html,
>> Please see https://incubator.apache.org/guides/distribution.html.

The first sentence of this page currently is "Apache OpenDAL™ Python binding".

As for the package name, I argued for the current guidelines in [1]
that you can follow. You may have different opinions and that's OK.
Xuanwo explained more technical details and community feedback in [1].

Best,
tison.

[1] https://lists.apache.org/thread/7t6670j2x5oo9wh2lvb7mxh6vy4ldo6q

Justin Mclean  于2023年12月27日周三 15:38写道：

>
> Hi,
>
> -1 (binding) to graduation, the PMC needs to understand the importance of and 
> follow our randing policy; something seems to have been missed here.
>
> > About the  https://opendal.apache.org/docs/python/opendal.html, it is
> > already on the apache.org site. It is obvious that it belongs to the
> > ASF.
>
> As part of the website, it needs to follow the ASF branding guidelines; there 
> are no expectations.
>
> > About other distribution platforms, using short names, rather than
> > apache or asf prefixes is a common practice.
>
> Please see https://incubator.apache.org/guides/distribution.html. It should 
> not be common practice.
>
> > For other projects, which are not controlled by the committers, it
> > takes time to add Apache. None of the found ones seem to hurt ASF
> > branding.
>
> The PMC needs to manage its brand and ASF’s trademarks, registered or 
> otherwise; it seems they have not been doing so.
>
> Kind Regards,
> Justin

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

Re: [DISCUSS] Graduate Apache OpenDAL (incubating) as a TLP - Incubator

[Xuanwo]

> I noticed the domain opendal.databend.rs mentioned there. Who owns that 
> domain?

The domain `opendal.databend.rs` is owned by Databend Labs and was used as the 
primary domain before OpenDAL entered the incubation stage. The PMC will 
coordinate
with Databend Labs to ensure that all instances are updated to 
`opendal.apache.org`.

> Other pages I click on have no mention of Apache. e.g. 
> https://opendal.apache.org/docs/python/opendal/layers.html Other 
> document pages have similar issues, e.g. 
> https://opendal.apache.org/docs/haskell/OpenDAL.html.

The pages are automatically generated API documentation, where the H1 header 
typically displays the package name.

On Thu, Dec 28, 2023, at 14:27, Justin Mclean wrote:
> Hi,
>
>> Thanks for your reply to report potential branding issues. The PMC is
>> actively responding to these comments.
>> 
>> * https://github.com/apache/incubator-opendal/pull/3829/files
>> * https://github.com/apache/incubator-opendal/pull/3830/files
>> * https://github.com/apache/incubator-opendal/pull/3831/files
>> * https://github.com/apache/incubator-opendal/pull/3833/files
>> * https://github.com/apache/incubator-opendal/pull/3838/files
>
> Thanks for that.
>
>> For third-party references, when a PMC member notices one that can be
>> confusing, there is a reaction:
>> 
>> * https://github.com/GreptimeTeam/greptimedb/pull/2653/files
>> * https://github.com/zwpaper/dilu/pull/1/files
>> * https://github.com/datafuselabs/databend-docs/pull/285/files
>
> I noticed the domain opendal.databend.rs mentioned there. Who owns that 
> domain?
>
>> These are instances for "manage its brand and ASF’s trademarks". I
>> believe that the PMC becomes more experienced on branding topics with
>> your reports; thank you.
>
> The point is I shouldn't have to report these; the (P)PMC should be 
> managing this on their own.
>
 About the https://opendal.apache.org/docs/python/opendal.html,
 Please see https://incubator.apache.org/guides/distribution.html.
>> 
>> The first sentence of this page currently is "Apache OpenDAL™ Python 
>> binding".
>
> But the first and more prominent mention of OpenDAL doesn’t include 
> Apache. The page is also missing mention of ASF’s trademarks. I think 
> you need a little more branding and naming is needed to comply with 
> ASF's policy.
>
> Other pages I click on have no mention of Apache. e.g. 
> https://opendal.apache.org/docs/python/opendal/layers.html Other 
> document pages have similar issues, e.g. 
> https://opendal.apache.org/docs/haskell/OpenDAL.html. I think a little 
> more work needs to be done here, and again, I shouldn't have to point 
> out the issues. Please look at your documentation and the policy and 
> see what needs to be fixed, or better still, discuss it on your mailing 
> list. It’s far better that you work out what needs to be corrected on 
> your own than for someone outside your project to list what might not 
> be in line with policy.
>
>> As for the package name, I argued for the current guidelines in [1]
>> that you can follow. You may have different opinions and that's OK.
>> Xuanwo explained more technical details and community feedback in [1].
>
> Other projects have different reasons for doing what they do; don’t 
> confuse that with permission to do what they do without a reason.
>
> Kind Regards,
> Justin

-- 
Xuanwo

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

Re: [DISCUSS] Graduate Apache OpenDAL (incubating) as a TLP - Incubator

[Justin Mclean]

Hi,

> The domain `opendal.databend.rs` is owned by Databend Labs and was used as 
> the 
> primary domain before OpenDAL entered the incubation stage. The PMC will 
> coordinate
> with Databend Labs to ensure that all instances are updated to 
> `opendal.apache.org`.

It would be best if the domain was controlled by the (P)PMC. Having a 3rd party 
in control of a domain that currently redirects to the ASF site is not ideal. 

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

Re: [DISCUSS] Branding in Thirdparty Platform Distribution

[Justin Mclean]

HI,


> Users should run `npm install xxx`, `pip install xxx`, or `cargo add xxx` 
> to include our library in their dependency list. Users should write code 
> in their own libraries or applications using statements such as `use xxx` 
> or `import xxx`. Adding the prefixes `apache-` or `asf-` could significantly
> increase the workload for the entire community. In severe cases, users may 
> halt library updates to prevent having to replace `xxx` throughout their code.

This is no different to any project that comes to the ASF via the incubator. 
Many of them need to change names, often before joining the incubator, and all 
need to change their name to be in the form “Apache Foo”.

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

Re: [DISCUSS] Graduate Apache OpenDAL (incubating) as a TLP - Incubator

[tison]

Hi Justin,

> I noticed the domain opendal.databend.rs mentioned there. Who owns that 
> domain?

As an analogy, think of answer.dev and answer.apache.org. You are in
the thread of a similar situation[1].

Best,
tison.

[1] https://lists.apache.org/thread/sj5nv4bhxl3xrm8yp01fkkrl1rkk3w8b

Xuanwo  于2023年12月28日周四 14:36写道：

>
> > I noticed the domain opendal.databend.rs mentioned there. Who owns that 
> > domain?
>
> The domain `opendal.databend.rs` is owned by Databend Labs and was used as the
> primary domain before OpenDAL entered the incubation stage. The PMC will 
> coordinate
> with Databend Labs to ensure that all instances are updated to 
> `opendal.apache.org`.
>
> > Other pages I click on have no mention of Apache. e.g.
> > https://opendal.apache.org/docs/python/opendal/layers.html Other
> > document pages have similar issues, e.g.
> > https://opendal.apache.org/docs/haskell/OpenDAL.html.
>
> The pages are automatically generated API documentation, where the H1 header
> typically displays the package name.
>
> On Thu, Dec 28, 2023, at 14:27, Justin Mclean wrote:
> > Hi,
> >
> >> Thanks for your reply to report potential branding issues. The PMC is
> >> actively responding to these comments.
> >>
> >> * https://github.com/apache/incubator-opendal/pull/3829/files
> >> * https://github.com/apache/incubator-opendal/pull/3830/files
> >> * https://github.com/apache/incubator-opendal/pull/3831/files
> >> * https://github.com/apache/incubator-opendal/pull/3833/files
> >> * https://github.com/apache/incubator-opendal/pull/3838/files
> >
> > Thanks for that.
> >
> >> For third-party references, when a PMC member notices one that can be
> >> confusing, there is a reaction:
> >>
> >> * https://github.com/GreptimeTeam/greptimedb/pull/2653/files
> >> * https://github.com/zwpaper/dilu/pull/1/files
> >> * https://github.com/datafuselabs/databend-docs/pull/285/files
> >
> > I noticed the domain opendal.databend.rs mentioned there. Who owns that 
> > domain?
> >
> >> These are instances for "manage its brand and ASF’s trademarks". I
> >> believe that the PMC becomes more experienced on branding topics with
> >> your reports; thank you.
> >
> > The point is I shouldn't have to report these; the (P)PMC should be
> > managing this on their own.
> >
>  About the https://opendal.apache.org/docs/python/opendal.html,
>  Please see https://incubator.apache.org/guides/distribution.html.
> >>
> >> The first sentence of this page currently is "Apache OpenDAL™ Python 
> >> binding".
> >
> > But the first and more prominent mention of OpenDAL doesn’t include
> > Apache. The page is also missing mention of ASF’s trademarks. I think
> > you need a little more branding and naming is needed to comply with
> > ASF's policy.
> >
> > Other pages I click on have no mention of Apache. e.g.
> > https://opendal.apache.org/docs/python/opendal/layers.html Other
> > document pages have similar issues, e.g.
> > https://opendal.apache.org/docs/haskell/OpenDAL.html. I think a little
> > more work needs to be done here, and again, I shouldn't have to point
> > out the issues. Please look at your documentation and the policy and
> > see what needs to be fixed, or better still, discuss it on your mailing
> > list. It’s far better that you work out what needs to be corrected on
> > your own than for someone outside your project to list what might not
> > be in line with policy.
> >
> >> As for the package name, I argued for the current guidelines in [1]
> >> that you can follow. You may have different opinions and that's OK.
> >> Xuanwo explained more technical details and community feedback in [1].
> >
> > Other projects have different reasons for doing what they do; don’t
> > confuse that with permission to do what they do without a reason.
> >
> > Kind Regards,
> > Justin
>
> --
> Xuanwo
>
> -
> 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