[jira] [Created] (CALCITE-3026) Release Avatica-Go 4.0.0
Francis Chuang created CALCITE-3026: --- Summary: Release Avatica-Go 4.0.0 Key: CALCITE-3026 URL: https://issues.apache.org/jira/browse/CALCITE-3026 Project: Calcite Issue Type: Improvement Components: avatica-go Reporter: Francis Chuang Assignee: Francis Chuang Fix For: avatica-go-4.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: calcite-test-dataset VM has issues with Druid
I also ran this issue, and make sure stop/up will definitely make Druid not work any more. Best, Danny Chan 在 2019年4月26日 +0800 AM7:10，dev@calcite.apache.org，写道： > > Stop/up definitely doesn't > work.
Re: Google BigQuery - zetasql parser/analyzer
I was intending to send an email about this, thanks for starting the discussion. I'm on the team at Google that is open sourcing ZetaSQL. It is a C++ SQL parser used internally for the BigQuery standard sql parser, among other things. We've open source the Java frontend and Rui currently working on a adapter between ZetaSQL and Calcite for Apache Beam, but we'd probably be interested in contributing it directly to Calcite Bable at some point. Any thoughts on that? Andrew On Thu, Apr 25, 2019 at 4:08 PM Kevin Risden wrote: > > https://github.com/google/zetasql > > Saw this come by on twitter not too long ago and figured share here since > it definitely overlaps with Calcite. > > Kevin Risden
[jira] [Created] (CALCITE-3025) Upgrade to Go 1.12
Francis Chuang created CALCITE-3025: --- Summary: Upgrade to Go 1.12 Key: CALCITE-3025 URL: https://issues.apache.org/jira/browse/CALCITE-3025 Project: Calcite Issue Type: Improvement Components: avatica-go Reporter: Francis Chuang Assignee: Francis Chuang Fix For: avatica-go-4.0.0 Upgrade to Go 1.12 and remove the DualStack setting from net.Dialer as it is now deprecated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-3024) Update avatica-go dependencies
Francis Chuang created CALCITE-3024: --- Summary: Update avatica-go dependencies Key: CALCITE-3024 URL: https://issues.apache.org/jira/browse/CALCITE-3024 Project: Calcite Issue Type: Improvement Components: avatica-go Reporter: Francis Chuang Assignee: Francis Chuang Fix For: avatica-go-4.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: calcite-test-dataset VM has issues with Druid
I ran into this when last trying to run the integration tests. https://github.com/vlsi/calcite-test-dataset/issues/29 I filed an issue but didn't follow up to figure out what the issues were. I know that druid works if you destroy/recreate. Stop/up definitely doesn't work. Kevin Risden On Thu, Apr 25, 2019 at 7:08 PM Valeriy Trofimov wrote: > Same with following steps described at > https://github.com/vlsi/calcite-test-dataset - running the "gfsh" command > shows "gfsh: command not found" error > > > On Thu, Apr 25, 2019 at 2:28 PM Valeriy Trofimov > wrote: > > > > > Hi All, > > > > Executing steps described at these links > > https://calcite.apache.org/docs/howto.html#running-integration-tests > > https://github.com/vlsi/calcite-test-dataset > > > > shows this error when accessing Druid data: > > curl: (7) Failed to connect to localhost port 8082: Connection refused > > > > Using "vagrant ssh" command and then "ps aux | grep > > org.apache.druid.cli.Main" shows that Druid is not running. Farhter > > research into the VM shows that it has scripts to isntall and run Druid > > (install.sh, run.sh) but they all fail: > > run.sh fails with the "No such file or directory" error and "Error: Could > > not find or load main class org.apache.druid.cli.Main" error > > > > The articles make it sound like Druid should be running after you > execute > > the "vagrant up" command. > > > > Thank, > > Val > > > > > > >
Re: calcite-test-dataset VM has issues with Druid
Same with following steps described at https://github.com/vlsi/calcite-test-dataset - running the "gfsh" command shows "gfsh: command not found" error On Thu, Apr 25, 2019 at 2:28 PM Valeriy Trofimov wrote: > > Hi All, > > Executing steps described at these links > https://calcite.apache.org/docs/howto.html#running-integration-tests > https://github.com/vlsi/calcite-test-dataset > > shows this error when accessing Druid data: > curl: (7) Failed to connect to localhost port 8082: Connection refused > > Using "vagrant ssh" command and then "ps aux | grep > org.apache.druid.cli.Main" shows that Druid is not running. Farhter > research into the VM shows that it has scripts to isntall and run Druid > (install.sh, run.sh) but they all fail: > run.sh fails with the "No such file or directory" error and "Error: Could > not find or load main class org.apache.druid.cli.Main" error > > The articles make it sound like Druid should be running after you execute > the "vagrant up" command. > > Thank, > Val > > >
Google BigQuery - zetasql parser/analyzer
https://github.com/google/zetasql Saw this come by on twitter not too long ago and figured share here since it definitely overlaps with Calcite. Kevin Risden
[CANCEL] [VOTE] Release apache-calcite-avatica-1.13.0 (release candidate 0)
The email was sent with the wrong subject. I will cancel this one and send a new one to the list. Apologies for the noise. Francis On 25/04/2019 10:24 pm, Francis Chuang wrote: Hi all, I have created a build for Apache Calcite Avatica 1.14.0, release candidate 0. Thanks to everyone who has contributed to this release. You can read the release notes here: https://github.com/apache/calcite-avatica/blob/branch-avatica-1.14/site/_docs/history.md The commit to be voted upon: https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=4fe0f9b8c7df2aa061caaff12e5ff02ceb8c02c0 Its hash is 4fe0f9b8c7df2aa061caaff12e5ff02ceb8c02c0. The artifacts to be voted on are located here: https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.14.0-rc0/ The hashes of the artifacts are as follows: src.tar.gz.sha512 58b264957da88c43ab1aa650a47b3728f9c94403a29ddf34d57d1fc24e8d4c005b58dd9f81fd6a0e7ce0dddbe6123a98f94b19c8cd760935890df4e78b5476c9 A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachecalcite-1058 Release artifacts are signed with the following key: https://people.apache.org/keys/committer/francischuang.asc If you do not have a Java environment available, you can run the tests using docker. To do so, install docker and docker-compose, then run docker-compose run test" from the root of the directory. Please vote on releasing this package as Apache Calcite Avatica 1.14.0. The vote is open for the next 72 hours and passes if a majority of at least three +1 PMC votes are cast. [ ] +1 Release this package as Apache Calcite 1.14.0 [ ] 0 I don't feel strongly about it, but I'm okay with the release [ ] -1 Do not release this package because... Here is my vote: +1 (binding) Francis
Re: JIRA usage reminders
Thanks for getting this discussion started, Stamatis! I was actually going to start some discussion regarding the "next" fix version/release on JIRA after making Avatica 1.14.0 rc0 available for voting, so I think this thread would be a good place to do so too. There are currently 18 issues on JIRA with the fix version set to "next" [1]. In my opinion this creates extra work for the release manager. For me, I open the list of commits on Github and check that the corresponding issue in JIRA (if any) has the correct fix version set and has been resolved. Unfortunately, some issues were tagged as "next" and I had to hunt those issues down individually and fix them, rather than being able to get a list of them by visiting the avatica-1.14.0 page on JIRA.In addition, the "next" version does not seem meaningful to me, as we do know the version number of the next release. There also seem to be a few pretty old issues set to "next" but have not been worked on in a while. In my opinion, it would be better if these issues have their Fix Version set to blank instead, as it may give the wrong impression (false hope), that a fix is in progress. What do you guys think? If the "next" fix version should not be used, we should set the fix version of those issues to a proper version number or nothing and archive the "next" release, so that it cannot be used per these instructions [2]. Francis [1] https://issues.apache.org/jira/projects/CALCITE/versions/12329362 [2] https://community.atlassian.com/t5/Jira-questions/Is-it-possible-to-lock-a-version-prevent-selecting-version/qaq-p/400996 On 26/04/2019 1:10 am, Chunwei Lei wrote: Thanks very much for this, Stamatis. It is really helpful and +1 to add them to website. Best, Chunwei Best, Chunwei On Thu, Apr 25, 2019 at 10:43 PM Julian Hyde wrote: Thanks for this, Stamatis. Much needed. I agree with Vladimir that this should end up on the site, but it is appropriate that it starts as an email discussion, so that we can build consensus. A few more things. The subject line of a jira case (and a commit) is important. Crafting it is an art. It should imply what the end user was trying to do, in which component, and what symptoms were seen. If it’s not clear what the desired behavior is, rephrase: eg “Validator closes model file” to “Validator should not close model file”. Contributors to the case should feel free to rephrase and clarify the subject line. If you remove information while clarifying, put it in the description of the case. Design discussions may happen in varying places (email threads, github reviews) but the case is the canonical place for those discussions. Link to them or summarize them in the case. When implementing a case, especially a new feature, make sure that the case includes a functional specification of the change. E.g. “Add a IF NOT EXISTS clause to the CREATE TABLE command; the command is a no-op if the table already exists.” Update the description if the specification changes during design discussions or implementation. When implementing a feature or fixing a bug, endeavor to create the jira case before you start work on the code. This gives others the opportunity to shape the feature before you have gone too far down (what the reviewer considers to be) the wrong path. Julian On Apr 25, 2019, at 6:51 AM, Vladimir Sitnikov wrote: Stamatis> If you see things that are Stamatis> incorrect or that need to be done differently feel free to reply to this Stamatis> email. LGTM. Stamatis, thanks for the writeup, however I'm inclined to suppose it makes sense to put that on the website. Such mails will be hard to find, especially for the ones who don't know such a mail exists at all. On the other hand, "/develop/" page is trivial to navigate even by just browsing the website. Vladimir
calcite-test-dataset VM has issues with Druid
Hi All, Executing steps described at these links https://calcite.apache.org/docs/howto.html#running-integration-tests https://github.com/vlsi/calcite-test-dataset shows this error when accessing Druid data: curl: (7) Failed to connect to localhost port 8082: Connection refused Using "vagrant ssh" command and then "ps aux | grep org.apache.druid.cli.Main" shows that Druid is not running. Farhter research into the VM shows that it has scripts to isntall and run Druid (install.sh, run.sh) but they all fail: run.sh fails with the "No such file or directory" error and "Error: Could not find or load main class org.apache.druid.cli.Main" error The articles make it sound like Druid should be running after you execute the "vagrant up" command. Thank, Val
Calcite-Master - Build # 1136 - Failure
The Apache Jenkins build system has built Calcite-Master (build #1136) Status: Failure Check console output at https://builds.apache.org/job/Calcite-Master/1136/ to view the results.
Re: JIRA usage reminders
Thanks very much for this, Stamatis. It is really helpful and +1 to add them to website. Best, Chunwei Best, Chunwei On Thu, Apr 25, 2019 at 10:43 PM Julian Hyde wrote: > > Thanks for this, Stamatis. Much needed. > > I agree with Vladimir that this should end up on the site, but it is > appropriate that it starts as an email discussion, so that we can build > consensus. > > A few more things. > > The subject line of a jira case (and a commit) is important. Crafting it is > an art. It should imply what the end user was trying to do, in which > component, and what symptoms were seen. If it’s not clear what the desired > behavior is, rephrase: eg “Validator closes model file” to “Validator should > not close model file”. Contributors to the case should feel free to rephrase > and clarify the subject line. If you remove information while clarifying, put > it in the description of the case. > > Design discussions may happen in varying places (email threads, github > reviews) but the case is the canonical place for those discussions. Link to > them or summarize them in the case. > > When implementing a case, especially a new feature, make sure that the case > includes a functional specification of the change. E.g. “Add a IF NOT EXISTS > clause to the CREATE TABLE command; the command is a no-op if the table > already exists.” Update the description if the specification changes during > design discussions or implementation. > > When implementing a feature or fixing a bug, endeavor to create the jira case > before you start work on the code. This gives others the opportunity to shape > the feature before you have gone too far down (what the reviewer considers to > be) the wrong path. > > Julian > > > On Apr 25, 2019, at 6:51 AM, Vladimir Sitnikov > > wrote: > > > > Stamatis> If you see things that are > > Stamatis> incorrect or that need to be done differently feel free to > > reply to this > > Stamatis> email. > > > > LGTM. > > > > Stamatis, thanks for the writeup, however I'm inclined to suppose it > > makes sense to put that on the website. > > > > Such mails will be hard to find, especially for the ones who don't > > know such a mail exists at all. > > On the other hand, "/develop/" page is trivial to navigate even by > > just browsing the website. > > > > Vladimir
Re: JIRA usage reminders
Thanks for this, Stamatis. Much needed. I agree with Vladimir that this should end up on the site, but it is appropriate that it starts as an email discussion, so that we can build consensus. A few more things. The subject line of a jira case (and a commit) is important. Crafting it is an art. It should imply what the end user was trying to do, in which component, and what symptoms were seen. If it’s not clear what the desired behavior is, rephrase: eg “Validator closes model file” to “Validator should not close model file”. Contributors to the case should feel free to rephrase and clarify the subject line. If you remove information while clarifying, put it in the description of the case. Design discussions may happen in varying places (email threads, github reviews) but the case is the canonical place for those discussions. Link to them or summarize them in the case. When implementing a case, especially a new feature, make sure that the case includes a functional specification of the change. E.g. “Add a IF NOT EXISTS clause to the CREATE TABLE command; the command is a no-op if the table already exists.” Update the description if the specification changes during design discussions or implementation. When implementing a feature or fixing a bug, endeavor to create the jira case before you start work on the code. This gives others the opportunity to shape the feature before you have gone too far down (what the reviewer considers to be) the wrong path. Julian > On Apr 25, 2019, at 6:51 AM, Vladimir Sitnikov > wrote: > > Stamatis> If you see things that are > Stamatis> incorrect or that need to be done differently feel free to > reply to this > Stamatis> email. > > LGTM. > > Stamatis, thanks for the writeup, however I'm inclined to suppose it > makes sense to put that on the website. > > Such mails will be hard to find, especially for the ones who don't > know such a mail exists at all. > On the other hand, "/develop/" page is trivial to navigate even by > just browsing the website. > > Vladimir
Re: JIRA usage reminders
Thank you very much for the summarizing, Stamatis! And +1 to documenting them to website. But still one thing I'm not pretty much sure: > There are cases where the JIRA issue may be solved in the discussion (or > some other reason) without necessitating a change. In such cases, the > contributor or committer involved in the discussion should: > - resolve the issue (not close it); > - ... If a JIRA issue is both tagged "Resolution: Not A Bug/Problem" and "Fix version: 1.20.0", that is going to look wired to me. Because we rarely need to fix a non-existing bug/problem in a specific release. Should we use "closed" instead? Thanks, Hongze > On Apr 25, 2019, at 21:51, Vladimir Sitnikov > wrote: > > Stamatis> If you see things that are > Stamatis> incorrect or that need to be done differently feel free to > reply to this > Stamatis> email. > > LGTM. > > Stamatis, thanks for the writeup, however I'm inclined to suppose it > makes sense to put that on the website. > > Such mails will be hard to find, especially for the ones who don't > know such a mail exists at all. > On the other hand, "/develop/" page is trivial to navigate even by > just browsing the website. > > Vladimir
Re: JIRA usage reminders
+1 for adding the notes to website Vladimir Sitnikov 于2019年4月25日 周四下午9:52写道： > Stamatis> If you see things that are > Stamatis> incorrect or that need to be done differently feel free to > reply to this > Stamatis> email. > > LGTM. > > Stamatis, thanks for the writeup, however I'm inclined to suppose it > makes sense to put that on the website. > > Such mails will be hard to find, especially for the ones who don't > know such a mail exists at all. > On the other hand, "/develop/" page is trivial to navigate even by > just browsing the website. > > Vladimir >
Re: JIRA usage reminders
Stamatis> If you see things that are Stamatis> incorrect or that need to be done differently feel free to reply to this Stamatis> email. LGTM. Stamatis, thanks for the writeup, however I'm inclined to suppose it makes sense to put that on the website. Such mails will be hard to find, especially for the ones who don't know such a mail exists at all. On the other hand, "/develop/" page is trivial to navigate even by just browsing the website. Vladimir
JIRA usage reminders
Hello,
The past few months I've noticed that people (committers and contributors)
use the tracking system in various different ways. In most cases, this is
not really problem but if we could manage to do some things in a more
uniform manner maybe the release process and various other tasks could be
simpler and possibly more efficient.
Before creating new issues, please perform a search and verify if an
existing issue already exists.
If a new issue needs to be created, try to provide a concise description of
the problem/improvement/evolution/change that needs to be made.
Please avoid tagging specific people in the description of the JIRA asking
for feedback. This discourages other contributors to participate in the
discussion and provide valuable feedback. Feel free to tag somebody in the
discussion if there is a regression that seems to be related with a
particular commit. The best place to ask for feedback related to an issue
is the dev@calcite list.
The assignee of the issue should mark it as in progress, if he/she is
working actively on it. When the change is ready, the contributor should
submit a PR using the instructions on the site and add the label
"pull-request-available" if that is not done automatically.
Possible solutions for resolving the issue must be part of the discussion
in the JIRA and ideally not in the PR it self. Comments in the PR are
encouraged when the discussion concerns particular lines of code.
After merging a PR that corresponds to a JIRA case, the committer must:
- resolve the issue (not close it);
- select "Fixed" as resolution cause;
- mark the appropriate version (e.g., for now we use 1.20.0) in the "Fix
version" field;
- add a comment (e.g., "Fixed in ...") with a hyperlink pointing to the
commit which resolves the issue (in github or gitbox).
There are cases where the JIRA issue may be solved in the discussion (or
some other reason) without necessitating a change. In such cases, the
contributor or committer involved in the discussion should:
- resolve the issue (not close it);
- select the appropriate resolution cause ("Duplicate", "Invalid",
"Won't fix", etc.);
- add a comment with the reasoning if that's not obvious;
The release manager should close all issues mark as resolved when
publishing the release adding an appropriate comment (i.e., "Resolved in
release X.Y.Z (-MM-DD)").
The items above are guidelines that exist in the website or things that
appeared in other discussions in the past. If you see things that are
incorrect or that need to be done differently feel free to reply to this
email.
Best,
Stamatis
[VOTE] Release apache-calcite-avatica-1.13.0 (release candidate 0)
Hi all, I have created a build for Apache Calcite Avatica 1.14.0, release candidate 0. Thanks to everyone who has contributed to this release. You can read the release notes here: https://github.com/apache/calcite-avatica/blob/branch-avatica-1.14/site/_docs/history.md The commit to be voted upon: https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=4fe0f9b8c7df2aa061caaff12e5ff02ceb8c02c0 Its hash is 4fe0f9b8c7df2aa061caaff12e5ff02ceb8c02c0. The artifacts to be voted on are located here: https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.14.0-rc0/ The hashes of the artifacts are as follows: src.tar.gz.sha512 58b264957da88c43ab1aa650a47b3728f9c94403a29ddf34d57d1fc24e8d4c005b58dd9f81fd6a0e7ce0dddbe6123a98f94b19c8cd760935890df4e78b5476c9 A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachecalcite-1058 Release artifacts are signed with the following key: https://people.apache.org/keys/committer/francischuang.asc If you do not have a Java environment available, you can run the tests using docker. To do so, install docker and docker-compose, then run docker-compose run test" from the root of the directory. Please vote on releasing this package as Apache Calcite Avatica 1.14.0. The vote is open for the next 72 hours and passes if a majority of at least three +1 PMC votes are cast. [ ] +1 Release this package as Apache Calcite 1.14.0 [ ] 0 I don't feel strongly about it, but I'm okay with the release [ ] -1 Do not release this package because... Here is my vote: +1 (binding) Francis
Re: a new adapter for Apache Kafka
Thank you @Andrei @Michael. Currently it's a straightforward implementation of stream ScannableTable, a site page is added for usage. Kindly let me know if something important is not covered. Mingmin On Wed, Apr 24, 2019 at 1:24 PM Michael Mior wrote: > I think we'd generally be willing to accept any adapter which is > well-written, well-tested, and likely to be generally useful. I think > Kafka meets the final criterion and with some work the current code > could meet the first two. That said, even if the adapter isn't > accepted into the main Calcite codebase, I would encourage you to > publish it as a separate package anyway. > -- > Michael Mior > mm...@apache.org > > Le mer. 24 avr. 2019 à 08:07, Andrei Sereda a écrit : > > > > Hi Mingmin, > > > > I'm happy to review it. > > > > Before would like to confirm with this list that they're OK adding new > > adapter (kafka) to calcite codebase ? > > > > Regards, > > Andrei. > > > > On Tue, Apr 23, 2019 at 10:43 PM Mingmin Xu wrote: > > > > > Hi all, > > > > > > I add a new adapter for Apache Kafka, to allow users to query Kafka > topics > > > with Calcite STREAM SQL. Can someone take a look at the PR[1]? > > > > > > [1]. https://github.com/apache/calcite/pull/1127 > > > > > > Thanks! > > > Mingmin > > > > -- Mingmin
