Virtual key signing party
Hello, The last virtual key signing party [1] was quite some time ago [2]. I would propose to hold another one in the next few days. I would like to propose the following slot: https://s.apache.org/t9x3e If you would like to attend, please reply to this thread with your public keys' fingerprint (gpg --fingerprint) before the meeting. pub rsa4096 2019-03-15 [SC] [expires: 2023-03-15] 0474 9577 FD93 4674 B9CD 45C5 D77C 3383 F192 7570 uid [ultimate] Stamatis Zampetakis uid [ultimate] Stamatis Zampetakis sub rsa4096 2019-03-15 [E] [expires: 2023-03-15] To verify your identity, please bring with you a government issued ID (preferably passport). If there are people who would like to attend but the date/time is not convenient feel free to propose an alternative slot. As a reminder of the procedure have a look in the notes [1] took by Francis during a previous party! Anybody can participate (not need to be a committer to the project). Best, Stamatis [1] http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html [2] https://lists.apache.org/thread.html/771b3709cfe7763a01cea67861484600b93a8754bc270268ae23f29e%40%3Cdev.calcite.apache.org%3E [3] https://gist.github.com/F21/b0e8c62c49dfab267ff1d0c6af39ab84
Re: [VOTE] Release apache-calcite-1.23.0 (release candidate 1)
>Looks like it is expected:
>https://github.com/gradle/gradle/issues/9758
It is not expected.
The way to fix it is to apply the following patch:
--- a/buildSrc/build.gradle.kts
+++ b/buildSrc/build.gradle.kts
@@ -19,7 +19,6 @@ import com.github.vlsi.gradle.properties.dsl.props
import org.jetbrains.kotlin.gradle.tasks.KotlinCompile
plugins {
-java
`kotlin-dsl` apply false
id("com.github.autostyle")
id("com.github.vlsi.gradle-extensions")
@@ -75,6 +74,6 @@ fun Project.applyKotlinProjectConventions() {
dependencies {
subprojects.forEach {
-runtimeOnly(project(it.path))
+"runtimeOnly"(project(it.path))
}
}
Vladimir
Re: [VOTE] Release apache-calcite-1.23.0 (release candidate 1)
> * the first line printed by gradle is ':jar: No valid plugin > descriptors were found in META-INF/gradle-plugins'; I don't know > whether this is bad, but it looks bad Looks like it is expected: https://github.com/gradle/gradle/issues/9758 On 2020/05/21 18:41:41, Julian Hyde wrote: > -1 because of signature issues noted in previous email (hoping I'm mistaken). > > Downloaded, checked build instructions, LICENSE, NOTICE, ran RAT, > compiled and ran tests using gradlew (Ubuntu 20.04 and JDK 14), > compared contents of source distro with contents of git. > > * howto.md doesn't mention JDK 14 as a valid release > * the line 'cd calcite-1.23.0' should be 'cd apache-calcite-1.23.0-src' > * the first line printed by gradle is ':jar: No valid plugin > descriptors were found in META-INF/gradle-plugins'; I don't know > whether this is bad, but it looks bad > * following the instructions in howto.md builds a release > '1.23.0-SNAPSHOT'; instructions should say how to build '1.23.0' > * LICENSE file in the source distro has a few extra lines compared to > the one in git > * in release notes: > ** 'fastest version of Calcite' is a bit hyperbolic; I would state > that there have been performance improvements in the planner engine > and hyperlink to a JIRA case > ** I think quite a few of the 'new features' that extend an existing > component to a new class (e.g supporting Exchange in RelFieldTrimmer) > should be listed as bug-fixes; > ** all class names need to be in back-ticks; all SQL keywords need to > be upper-case and in back-ticks; > ** I don't like the long lines - can we go back to breaking at 80? > ** In 'it's worth mentioning the following', remove JIRA case numbers > so that the paragraph reads like prose rather than a list. > > > On Thu, May 21, 2020 at 10:57 AM Julian Hyde wrote: > > > > Maybe I'm mistaken, but the source tarball doesn't seem to be signed: > > > > $ gpg --verify apache-calcite-1.23.0-src.tar.gz.asc > > apache-calcite-1.23.0-src.tar.gz > > gpg: Signature made Fri 15 May 2020 08:52:43 PM PDT > > gpg:using RSA key ECA9CF33AF2CEC28F3B66A5C3CD22ABAC50DDCEF > > gpg: Can't check signature: No public key > > > > I have imported Haisheng's keys successfully: > > > > $ gpg --recv-keys "A663 E308 27C3 5F7C F578 B4F0 41CA B58D 1DA9 7F7D" > > gpg: key 41CAB58D1DA97F7D: "Haisheng Yuan " not changed > > gpg: Total number processed: 1 > > gpg: unchanged: 1 > > > > Julian > > > > On Wed, May 20, 2020 at 10:12 PM Rui Wang wrote: > > > > > > I built the site both from the repo (git tag) and > > > apache-calcite-1.23.0-src.tar.gz, launched the site locally and spot > > > checked. From what I could tell, there wasn't an obvious difference > > > (random > > > clicks were limited though). > > > > > > My personal opinion is that the 1.23.0 rc1 can continue. If someone knows > > > the exact impact of this diff, we could add it to the release note, in the > > > category of "known issues". > > > > > > > > > -Rui > > > > > > On Wed, May 20, 2020 at 9:33 PM Rui Wang wrote: > > > > > > > Indeed there is an extra site/fonts in the git tag. I didn't see it in > > > > the > > > > last two releases (the diff on licenses are normal). > > > > > > > > So the question is, does it matter for the diff on site/? At least the > > > > artifact has the same source code as the tag (thus can build the same > > > > jar, > > > > behave the same when run same queries, etc.) Also the site/ seems not > > > > related to javadoc either. > > > > > > > > > > > > -Rui > > > > > > > > On Wed, May 20, 2020 at 3:53 PM Stamatis Zampetakis > > > > wrote: > > > > > > > >> 5.3.0-51-generic #44~18.04.2-Ubuntu, jdk1.8.0_251, Gradle wrapper > > > >> > > > >> * Checked signatures and checksums OK > > > >> * Build (./gradlew clean assemble) on git repo and source artifacts OK > > > >> * Run unit tests (./gradlew clean test) on git repo and source > > > >> artifacts > > > >> OK > > > >> * Run slow tests (./gradlew clean testSlow) on git repo and source > > > >> artifacts OK > > > >> * Checked diff between git commit and source artifacts > > > >> Apart from some differences in the licenses I see that the git tag has > > > >> a > > > >> folder site/fonts while the source artifacts do not. > > > >> * Went over release note OK > > > >> > > > >> The following issues should be added in the breaking changes section: > > > >> https://issues.apache.org/jira/browse/CALCITE-3825 > > > >> https://issues.apache.org/jira/browse/CALCITE-3938 > > > >> > > > >> There are few typos and other minor improvements (like quoting SQL > > > >> keywords > > > >> and java classes) for the release note but all these can be done > > > >> post-release. > > > >> > > > >> My only concern for casting my vote is the site/fonts folder that is > > > >> present on the repo. I don't remember seeing this in the previous > > > >> releases. > > > >> Can somebody clarify if this is normal? > > > >> > > > >> Thanks again for your effort Haisheng
[jira] [Created] (CALCITE-4021) EnumerableUnion should preserve ordering when all inputs have the same collation
Rui Wang created CALCITE-4021:
-
Summary: EnumerableUnion should preserve ordering when all inputs
have the same collation
Key: CALCITE-4021
URL: https://issues.apache.org/jira/browse/CALCITE-4021
Project: Calcite
Issue Type: Improvement
Reporter: Rui Wang
For query:
"select name from sales_dept
union
select name from it_dept
order by mgr"
We could generate a plan based on
https://issues.apache.org/jira/browse/CALCITE-4017:
{code:java}
EnumerableUnion
EnumerableProject
EnumerableSort
EnumerableTableScan[name="sales_dept"]
EnumerableProject
EnumerableSort
EnumerableTableScan[name="it_dept"]
{code}
So EnumerableUnion should preserve ordering when all input have the same
collation to make sure result of query is correct.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [VOTE] Release apache-calcite-1.23.0 (release candidate 1)
Hi Vladimir, Thanks for your explanation. And thanks a lot for providing such an amazing release tool for us! Cheers, Haisheng On 2020/05/23 16:28:52, Vladimir Sitnikov wrote: > >But it said build successful. Is there anything I can do for the 404 Not > Found error? > > It means "staging repository no longer exists as it has just been released". > > I've raised https://github.com/gradle-nexus/publish-plugin/issues/29 to > heal that. > However, gradle-nexus/publish-plugin is not yet ready for use, so 404 will > be there for a while. > > Currently, we use https://github.com/Codearte/gradle-nexus-staging-plugin + > https://github.com/marcphilipp/nexus-publish-plugin, > however, I'm not eager to analyze and fix those because they both will be > superseded by a single gradle-nexus/publish-plugin > > Vladimir >
Re: [VOTE] Release apache-calcite-1.23.0 (release candidate 1)
>But it said build successful. Is there anything I can do for the 404 Not Found error? It means "staging repository no longer exists as it has just been released". I've raised https://github.com/gradle-nexus/publish-plugin/issues/29 to heal that. However, gradle-nexus/publish-plugin is not yet ready for use, so 404 will be there for a while. Currently, we use https://github.com/Codearte/gradle-nexus-staging-plugin + https://github.com/marcphilipp/nexus-publish-plugin, however, I'm not eager to analyze and fix those because they both will be superseded by a single gradle-nexus/publish-plugin Vladimir
Re: [VOTE] Release apache-calcite-1.23.0 (release candidate 1)
Hi, I had the following error when executing the command: ./gradlew publishDist -Prc=1 -Pasf > Task :releaseRepository Initialized stagingRepositoryId orgapachecalcite-1089 for repository nexus <==---> 50% EXECUTING [1m 17s] GET request failed. 404: Not Found, body: [errors:[[id:*, msg:No such repository: orgapachecalcite-1089]]] Requested operation was executed successfully in attempt 117 (maximum allowed 601) > Task :createReleaseTag Created tag calcite-1.23.0 -> Ref[refs/tags/calcite-1.23.0=7c3001d97497ca60b8e2039e8f3c96ca8672fae8(-1)] > Task :pushReleaseTag Pushing tag to Git remote release-origin: https://github.com/apache/calcite.git Message from release-origin: refs/tags/calcite-1.23.0: OK, 7c3001d97497ca60b8e2039e8f3c96ca8672fae8 (fastForward) BUILD SUCCESSFUL in 5m 0s 4 actionable tasks: 4 executed ~ But it said build successful. Is there anything I can do for the 404 Not Found error? Thanks, Haisheng On 2020/05/22 20:37:35, Laurent Goujon wrote: > My intent was not to cause sadness, sorry about that. > > I should have elaborated a bit more why I don't think Github is that much > of an issue: > - LICENSE file at the root of the project is the source of truth, not > Github mention. It is a nice to have the correct license for Github for > sure, but it seems more important to me to have LICENSE includes the 3rd > party dependencies present in our source tree than having the license > displayed at the top of the github UI. > > - As for the embox project you mentioned, it's probably because the license > is short and BSD licenses have very similar texts. Here's what license says > about the project: > > $ licensee detect https://github.com/embox/embox > License:NOASSERTION > Matched files: COPYRIGHT > COPYRIGHT: > Content hash: 77dc7c8c10d1ed9bc1546f2d6bba18a809e235c7 > License: NOASSERTION > Closest non-matching licenses: > BSD-2-Clause similarity: 89.59% > BSD-3-Clause similarity: 83.54% > BSD-4-Clause similarity: 77.82% > > $ licensee license-path https://github.com/embox/embox > COPYRIGHT > > Here's now what licensee says the LICENSE file from the source distribution > tarball: > > $ licensee detect ./apache-calcite-1.23.0-src > License:Apache-2.0 > Matched files: LICENSE > LICENSE: > Content hash: ab3901051663cb8ee5dea9ebdff406ad136910e3 > Confidence:100.00% > Matcher: Licensee::Matchers::Exact > License: Apache-2.0 > > $ licensee license-path ./apache-calcite-1.23.0-src > /xxx/apache-calcite-1.23.0-src/LICENSE > > It seems that adding several mentions at the bottom, licensee has no > trouble identifying the apache license because the text is so large and so > distinctive. It is corroborated by my own personal experience of checking > license for many many dependencies and comparing between Maven pom.xml, > github mention, and actual LICENSE/source file headers than when people are > using ASL 2.0, even with copyright mention + extra stuff after the main > text, Github gets it right. > > On Fri, May 22, 2020 at 12:32 PM Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > > > Laurent>As for Github, I think this is a non-issue > > > > I have provided an example: https://github.com/embox/embox > > It is an example when GitHub fails to detect the license. > > > > It is really sad to hear that "you think it is a non-issue" even in case > > you have seen the failure case. > > > > Laurent>on the source distribution and it has no issue identifying the > > license. > > > > The license might vary over time, and it would be very bad to end up with > > improperly detected license in GitHub. > > > > Vladimir > > >
