[jira] [Created] (CALCITE-5298) CalciteSystemProperty calcite.test.dataset path check fails under Java Security Manager
Kevin Risden created CALCITE-5298: - Summary: CalciteSystemProperty calcite.test.dataset path check fails under Java Security Manager Key: CALCITE-5298 URL: https://issues.apache.org/jira/browse/CALCITE-5298 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.32.0, 1.31.0, 1.30.0, 1.29.0, 1.28.0, 1.27.0 Reporter: Kevin Risden SOLR-16433 found that Calcite does not handle the Java security manager returning permission denied when checking that the calcite.test.dataset path exists. Solr runs with a security manager that doesn't allow arbitrary filesystem access. This failure causes Calcite to not load and therefore unusable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [Tests Failing] Master Travis test fails continuously for JDK14
We should be able to clear the Travis cache by ourselves. If you have your github and asf accounts linked: https://travis-ci.org/github/apache/calcite/caches That page is linked under the more options in the top right of the Calcite page. You should be able to clear all or some subset of caches. Kevin Risden On Mon, Apr 27, 2020 at 8:53 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > > Log an issue there ? > > An issue for INFRA project would probably do: > https://issues.apache.org/jira/projects/INFRA > > Vladimir >
Re: [ANNOUNCE] New committer: Feng Zhu
Congrats Feng! Sounds like an interesting project. Kevin Risden On Sun, Mar 1, 2020 at 5:34 AM Feng Zhu wrote: > Thanks Julian. > Let me make a brief introduction about the project. > SuperSQL relies on both Calcite and Avatica (with inner branch). It aims to > take the role as a unified entrance and middleware to connect various data > platforms in Tencent, including RDBMS、ES、Hive、Flink、Spark、Presto、ClickHouse > and some inner-built systems. They may be integrated as datasource or > execution engine. > > As we are still busy on migrating massive workloads and supporting in-house > business with SuperSQL, current now we do not have enough resources on > public release (e.g., presentation, talks or posts). Therefore, it is not > suprising that you wasn't aware of it before. > > Is it better to add the paragraph when we have website or an open-sourced > version (maybe several months later)? > > Tencent's logo can be found in bottom right-hand corner in ( > https://www.tencent.com/en-us/index.html). > I think you can just pick up the english part (i.e. "Tencent"). > > Best regards, > Feng > > Julian Hyde 于2020年3月1日周日 上午7:33写道： > > > Congratulations, thanks, and welcome! > > > > Feng, I wasn’t aware of Tencent’s SuperSQL project. It would be a great > > addition to the “powered by” page. If you would like to add it, please > > create a PR to add a paragraph to that page (no need for a JIRA case), > and > > provide a link to a logo for Tencent that I can add to the picture. > > > > Julian > > > > > > > > > On Feb 29, 2020, at 3:15 PM, Rui Wang wrote: > > > > > > Congratulations Feng! Well deserved! > > > > > > > > > > > > -Rui > > > > > > On Sat, Feb 29, 2020 at 2:10 AM Feng Zhu > wrote: > > > > > >> Thank you everyone for your warm welcome! > > >> Currently I am working at SuperSQL team of Tencent in Shenzhen, > > Guangdong, > > >> China. > > >> The project relies heavily on Calcite to analyze data residing in > > thousands > > >> of heterogeneous data sources. > > >> > > >> It is my greate honor to be part of the community. Calcite is an > > excellent > > >> and promising project! > > >> I will do my best to contribute to the project. > > >> > > >> Best regards, > > >> Feng > > >> > > >> Chunwei Lei 于2020年2月29日周六 下午4:46写道： > > >> > > >>> Congratulations！ > > >>> > > >>> > > >>> Best, > > >>> Chunwei > > >>> > > >>> > > >>> On Sat, Feb 29, 2020 at 4:41 PM Danny Chan > > wrote: > > >>> > > >>>> Congratulations! > > >>>> > > >>>> Francis Chuang 于2020年2月29日 周六下午4:35写道： > > >>>> > > >>>>> Congrats, well-deserved! > > >>>>> > > >>>>> On 29/02/2020 6:26 pm, Stamatis Zampetakis wrote: > > >>>>>> Apache Calcite's Project Management Committee (PMC) has invited > > >> Feng > > >>>>>> Zhu to become a committer, and we are pleased to announce that he > > >>>>>> has accepted. > > >>>>>> > > >>>>>> Feng is an active contributor and has contributed a lot of code to > > >>> some > > >>>>>> fairly complex parts of Calcite. He has been very helpful in > > >>>> discussions > > >>>>>> and reviews, especially around code generation, and his work is > > >>> always > > >>>>>> of high quality. > > >>>>>> > > >>>>>> Feng, welcome, thank you for your contributions, and we look > > >> forward > > >>>>>> your further interactions with the community! If you wish, please > > >>> feel > > >>>>>> free to tell us more about yourself and what you are working on. > > >>>>>> > > >>>>>> Stamatis (on behalf of the Apache Calcite PMC) > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > >
Re: Calcite example code
Vladimir since on a different thread you asked about playground. As a side note, it might be interesting to have Calcite playground. > It could be like https://rextester.com/l/postgresql_online_compiler but > with Calcite inside. > Michael had setup one with jupyter and binder. Its not exactly the same thing, but definitely allows playing around with Calcite. https://github.com/michaelmior/calcite-notebooks Kevin Risden On Thu, Dec 20, 2018 at 12:48 PM Michael Mior wrote: > Here's another one focused on basic query optimization > > > https://github.com/michaelmior/calcite-notebooks/blob/master/query-optimization.ipynb > > -- > Michael Mior > mm...@apache.org > > > Le mer. 19 déc. 2018 à 18:21, Michael Mior a écrit : > > > Yes the notebook contains the output (it's really just a JSON file). It > > doesn't necessarily have to have output, but it's much more useful if it > > does since it means whoever is viewing doesn't need to execute it. It > would > > certainly be possible to use this for tests although it would require an > > installation of Python. Given how ubiquitous Python is, I don't think > this > > is a huge concern, although we'd need a way of installing a couple Python > > dependencies. > > > > As Kevin mentioned, you can execute these online with Binder. I just had > > to add a Dockerfile so it could run the IJava kernel since it not the > > default. Check out the link below and you can see what the experience is > > like. > > > > https://mybinder.org/v2/gh/michaelmior/calcite-notebooks/master > > > > Just select a notebook once it loads (it may take a couple minutes). The > > experience is basically the same as what you get when running locally. > The > > notebook consists of a series of "cells" which you can run individually > and > > edit as you wish. This would also make it easy for people to play around > > with Calcite a little without having to install anything. > > > > -- > > Michael Mior > > mm...@apache.org > > > > > > Le mer. 19 déc. 2018 à 17:22, Julian Hyde a écrit : > > > >> For old idiots like me, can you explain how the notebook works? The file > >> you checked into GitHub, does it contain the input and output or just > the > >> input? Is there a way to edit or use the notebook interactively? > >> > >> It certainly seems a better way to introduce people to examples than > >> saying “go look at this test”. > >> > >> I think quite a few of our tests could be converted into this format. > >> > >> Julian > >> > >> > >> > On Dec 19, 2018, at 10:52 AM, Michael Mior wrote: > >> > > >> > After seeing so many people ask for example code to do certain basic > >> things > >> > in Calcite, I've been trying to find a good literate programming > >> solution > >> > for Java as I like this approach for demoing. I recently came across > the > >> > IJava (https://github.com/SpencerPark/IJava) kernel for Jupyter > >> notebooks. > >> > > >> > This is basically just a proof of concept at this point, but here's a > >> > simple example > >> > > >> > > >> > https://github.com/michaelmior/calcite-notebooks/blob/master/Query%20parsing.ipynb > >> > > >> > I'm curious what others think of this approach. If others think it > >> would be > >> > useful, I'd be happy to take suggestions on what should be included. > >> > Eventually, I'd like to get CI set up for this repository so I can > >> re-run > >> > the notebooks at will. I would then aim to check this on every release > >> so > >> > we can have a repository of code samples which we know run correctly. > >> > > >> > -- > >> > Michael Mior > >> > mm...@apache.org > >> > >> >
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
I haven't looked into this in detail yet, but can share details on one of
the questions:
> - Can anyone confirm if the
> avatica-standalone-server-${AVATICA_VERSION}-shaded.jar and
> avatica-standalone-server-${AVATICA_VERSION}.jar.
> jars are suppose to be equivalent?
>
The Maven built used the maven-shade-plugin to build a jar with all the
dependencies included. It could shaded dependencies if needed, but from
what I remember it was only for putting all the dependencies into a single
jar. Maven would typically leave the .jar alone and then would have a
-shaded.jar next to it with all the dependencies.
I don't know what the gradle build is doing in this case. The easiest way
to look is to see if the new .jar is close to the same size as the old
-shaded.jar. The new and old versions should be comparable on Nexus.
Kevin Risden
On Wed, Dec 18, 2019 at 9:59 PM Francis Chuang
wrote:
> Upon finalizing the release for Avatica 1.16.0, I noticed that the
> dockerfiles would not build on docker hub. Upon investigation, it
> appears that the file names of the jars on nexus has changed slightly.
>
> The current dockerfiles [1] references
>
> https://repository.apache.org/content/groups/public/org/apache/calcite/avatica/avatica-standalone-server/${AVATICA_VERSION}/avatica-standalone-server-${AVATICA_VERSION}-shaded.jar
>
> Where as on nexus, they are now called
> avatica-standalone-server-${AVATICA_VERSION}.jar.
>
> - Can anyone confirm if the
> avatica-standalone-server-${AVATICA_VERSION}-shaded.jar and
> avatica-standalone-server-${AVATICA_VERSION}.jar.
> jars are suppose to be equivalent?
>
>
> - Since the docker images for 1.16.0 cannot be built, I think we ought
> to fix the dockerfiles and release a 1.17.0.
>
> Francis
>
> [1]
>
> https://github.com/apache/calcite-avatica/tree/master/docker/src/main/dockerhub
>
Re: [DISCUSS] Remove Kotlin
> > I believe that writing is not great to understand somebody's tone and > intentions and many things can be misunderstood. Maybe for this and other > similar issues we should try to hold live discussions. Shall we try to organize an online meeting? I think this is a good idea to try. I think a few other projects do this. Aligning schedules and stuff is always hard, but willing to try to attend a meeting. Kevin Risden On Wed, Dec 18, 2019 at 8:27 AM Stamatis Zampetakis wrote: > Calcite wouldn't be a great project without Julian's and Vladimir's > contributions. Everybody wants the best for the project and we should work > out to find a solution. > > I believe that writing is not great to understand somebody's tone and > intentions and many things can be misunderstood. Maybe for this and other > similar issues we should try to hold live discussions. > > Shall we try to organize an online meeting? > > Best, > Stamatis > > On Wed, Dec 18, 2019, 2:25 AM Albert wrote: > > > I've used the new version calcite with new version of IntelliJ, > everything > > works. I like that. > > I can see valadmir put some efforts in this, I respect that. and all > effort > > put in to the codebase should be respected. > > from my side, I don't contribute as much now, but occasionally I would > look > > at the new stuff added so as long I can REPL the code I am okay with it. > > as for 'kotlin', like when it was first brought up in the calcite mail > > thread, I am curious about that and would be willing to learn more. > > > > > > > > On Wed, Dec 18, 2019 at 7:45 AM Michael Mior wrote: > > > > > Le mar. 17 déc. 2019 à 15:26, Vladimir Sitnikov > > > a écrit : > > > > > > > > Vladimir>Quidem, CalciteAssert > > > > Michael>If you want to propose removing either of these, we could > have > > a > > > > Michael>discussion about it, but you're talking about code which is > > > already > > > > Michael>heavily used throughout Calcite. > > > > > > > > The point of "we assume contributors are good at Java, thus we must > > keep > > > > the code to be Java-only" is weak. > > > > New contributors will likely see Quidem and CalciteAssert for the > first > > > > time, and Java knowledge does not help there. > > > > > > > > > > I didn't make that point. Those are you words. > > > > > > > It does not imply that languages like Quidem and/or CalciteAssert > are a > > > bad > > > > fit for their job, but it is wrong to judge > > > > based solely on "it is not Java". > > > > > > > > Michael>The consensus from the discussion you started seems to be > that > > > > Michael>Kotlin should not be added to the tests > > > > > > > > It is not like that. > > > > > > I counted at least 5 different contributors stating they did not think > > > Kotlin should be introduced into test code. You seemed to be the only > > > one in the discussion strongly promoting it. If that's not consensus, > > > I must have misinterpreted the discussion. > > > > > > > > > > > Michael>I agree that for these specific tests, readability is > improved > > > > > > > > That is exactly my point. There's an improvement, the downsides are > > > small, > > > > so I just committed it. > > > > > > > > Michael>But many tests require more than this > > > > > > > > That is to be discussed on a test by test basis (or use-case by > > > use-case). > > > > For instance, strings (especially, multi-line ones) with $ is an > issue > > > for > > > > Kotlin for now. > > > > > > > > Vladimir > > > > > > > > > -- > > ~~~ > > no mistakes > > ~~ > > >
Re: [DISCUSS] Remove Kotlin
> > Kevin, what is your opinion on removing Quidem language? > Completely unrelated to the topic at hand. This is specifically about Kotlin. It is sad you mention "code readability" as "little benefit currently" item. Please don't put words into my mouth. I have nothing wrong with improving code readability, but this is subjective. Adding an entirely new language for some minor code readability improvements is a poor tradeoff. The cost to maintain the new language easily outweighs the multiline strings. Switching tests from one language to another and reformatting removes the history for that file. This makes it much harder to maintain tests over time. It is not introducing a brand new language. The very same language is used > in the build scripts. > This is a circular argument. You could say that the build scripts language is not new since its in a few tests. This doesn't lend any credibility to keeping Kotlin. It is a new language to Calcite. It was added recently therefore new. Those are two different items. The discussion re $ is still open, and > there's no clear answer yet. > At the same time, in the very same thread, there were explicit opinions > that "tests that do not use $ might still benefit from improved > readability". > The change in [2] is not related to the $-discussion, so I don't see > whypeople relate them. The subject of the email was "[DISCUSS] Tests vs multiline strings" and every response was against the change. The change made in https://github.com/apache/calcite/commit/b93ec5a9edb7459696385e6adad67b92b6d406d7 is explicitly switching from Java to Kotlin for multiline strings. The only substantial change between the two files is the multiline strings. This absolutely is related to the email thread where 9 replies were against the change. The clear answer was do not do it. It is not still open. It is not wait longer for more people to chime in. It is not wait a bit and push the change in anyway. It is not start another thread to try to force a change it. The clear response was do not do it. The change was still made anyway. It looks like you express an opinion on "let's rewrite everything in > Kotlin" rather than "let's pick the proper tools on a case by case basis". This is completely false. This is putting words into my mouth again. This is not a quote I said in either case. I am basing my opinion on the amount of friction this has caused in the community. Multiple email threads where the support to add Kotlin was never there to begin with means that it is not a perfect tool. Picking any tool over the community feedback is short term thinking. Kevin Risden On Tue, Dec 17, 2019 at 3:30 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Kevin>Focusing on the technical side of things, I agree that introducing a > new > Kevin>language is of little benefit currently > > Kevin, what is your opinion on removing Quidem language? > Focusing on the technical side, it is a standalone language. > The language is not Java, it has limited tooling, it has a limited set of > users, it has 0 or so questions on StackOverflow and so on. > > Kevin>I agree that introducing a new > Kevin>language is of little benefit currently > > Keeping tests easy to read, easy to edit, easy to create, easy to debug, > and easy to maintain is hard. > Making tests easy to read simplifies code reviews that pay off in the long > run. > It is sad you mention "code readability" as "little benefit currently" > item. > > Kevin>surprised that a change went in to > Kevin>switch to Kotlin especially after the discussion that is happening on > the > Kevin>mailing list. > > Those are two different items. The discussion re $ is still open, and > there's no clear answer yet. > At the same time, in the very same thread, there were explicit opinions > that "tests that do not use $ might still benefit from improved > readability". > > The change in [2] is not related to the $-discussion, so I don't see why > people relate them. > > Kevin>I agree that introducing a new > Kevin>language is of little benefit currently > > It is not introducing a brand new language. The very same language is used > in the build scripts. > The language was designed for interoperability with Java, and it does > improve things if used appropriately. > > For instance, tests like > > https://github.com/apache/calcite/pull/1657/commits/0d6bec4140da46af07d58cf07a5e682d61529603#diff-7a7027c499b6e4f5e7448b7b971052f1R85-R94 > are > much easier to read and update than similar tests in Java. > > Note: Kotlin tests are still regular JUnit5 tests, so they get proper > statistics in the CI outputs like test count, skipped test count, failur
Re: [ANNOUNCE] New Calcite PMC chair: Stamatis Zampetakis
Congrats Stamatis! Kevin Risden On Wed, Dec 18, 2019 at 4:12 PM Francis Chuang wrote: > Calcite community members, > > I am pleased to announce that we have a new PMC chair and VP as per our > tradition of rotating the chair once a year. I have resigned, and > Stamatis was duly elected by the PMC and approved unanimously by the Board. > > Please join me in congratulating Stamatis! > > -Francis >
Re: [DISCUSS] Remove Kotlin
Focusing on the technical side of things, I agree that introducing a new language is of little benefit currently. I am not paying super close attention to the commits lately and am surprised that a change went in to switch to Kotlin especially after the discussion that is happening on the mailing list. When Kotlin was originally proposed it was also not a clear cut favorite [1]. Since it still seems to be causing angst, I am in favor of removing Kotlin altogether. In my opinion there are more negatives than positives currently. This is not to exclude the idea of moving to Kotlin at some point in the future, but the support is not there right now to keep including Kotlin. [1] http://mail-archives.apache.org/mod_mbox/calcite-dev/201809.mbox/%3cCAB=Je-F8BVTufLGBDTyX0fHQ=fd8ex8dr+8rlqt4fqm8jr0...@mail.gmail.com%3e Kevin Risden On Mon, Dec 16, 2019 at 3:44 PM Julian Hyde wrote: > Vladimir proposed that we convert some tests to Kotlin. The general > reaction was against the idea[1]. After receiving this feedback, he went > ahead anyway[2]. > > I propose that we remove all Kotlin from our source code, including tests. > The benefits of being a hybrid Java+Kotlin project do not outweigh the > negatives. We should go back to being solely Java. (I would make an > exception for build.gradle.kts, because build scripts are generally in a > different language.) > > Vladimir clearly has a lot of enthusiasm to change the build system, > coding style, the languages we use. I tend to be more conservative (don’t > fix things that aren’t broken). Speaking personally, I find working with > Vladimir extremely stressful. Of course, a lot of the things he is removing > are things that I personally have created, so I naturally take this more > personally than most people. Still, his actions over the last few weeks > have left me angry, depressed, and burned out with the project. > > Julian > > [1] > https://lists.apache.org/thread.html/c95bc24a10952ccaaa8ac1f959bf65aec450b8bf2fa36ba99dd0df08%40%3Cdev.calcite.apache.org%3E > < > https://lists.apache.org/thread.html/c95bc24a10952ccaaa8ac1f959bf65aec450b8bf2fa36ba99dd0df08@%3Cdev.calcite.apache.org%3E > > > > [2] > https://github.com/apache/calcite/commit/b93ec5a9edb7459696385e6adad67b92b6d406d7 > < > https://github.com/apache/calcite/commit/b93ec5a9edb7459696385e6adad67b92b6d406d7 > > > > >
Re: [DISCUSS] Tests vs multiline strings
I don't see a major benefit to switching to an entirely new language to get multiline strings. I agree that sticking to Java makes sense. Kevin Risden On Mon, Dec 16, 2019 at 12:50 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Feng>Introducing another language > > It is the same language that is used for the build scripts, so it is not a > new language. > > Danny> in the code evolving and the Scala has many > Danny> tricky problems especially the version compatibility > > Kotlin has strong backward compatibility. > > Julian>Transitioning our tests to a different language (Kotlin) is a > Julian> drastic solution. It requires developers to understand a new > language, > > Note: most of the time, test code is just a glue code between input data > and asserts. The complicated logic is not there (which is good by the way). > > At the same time, it means it will be very little new to understand. > > Vladimir >
Re: [VOTE] Release apache-calcite-avatica-1.16.0 (release candidate 1)
+1 (binding) * Check signatures and hashes * Checked src matches git hash - same comment about licenses as Stamtis * Checked build ran for git hash and src tar.gz * Checked Maven repo looks complete * Same comment as Stamatis about release notes being a bit rough to follow w/ all the commits. Kevin Risden On Mon, Dec 16, 2019 at 4:07 PM Francis Chuang wrote: > Hey everyone, > > Just a quick reminder that the vote for Avatica 1.16.0 rc1 is still open. > > Francis > > On 12/12/2019 9:20 am, Francis Chuang wrote: > > Hi all, > > > > I have created a build for Apache Calcite Avatica 1.16.0, release > > candidate 1. > > > > Thanks to everyone who has contributed to this release. > > > > You can read the release notes here: > > > https://github.com/apache/calcite-avatica/blob/512bbee4aa24ef9fb8106d0286d1243679dce2d0/site/_docs/history.md > > > > > > The commit to be voted upon: > > > https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=512bbee4aa24ef9fb8106d0286d1243679dce2d0 > > > > > > Its hash is 512bbee4aa24ef9fb8106d0286d1243679dce2d0 > > > > Tag: > > > https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=tag;h=refs/tags/avatica-1.16.0-rc1 > > > > > > The artifacts to be voted on are located here: > > > https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.16.0-rc1 > > > > (revision 37181) > > > > The hashes of the artifacts are as follows: > > > 102d3ab0e90dd1db5e012a966d265bdfa8a0f24f9016a4187a6e5f0135a14770da124493dd2c7a18c9d8d8b9af5ecf4f5aceb90d48421251f38bc6ce6f5be697 > > > > > *apache-calcite-avatica-1.16.0-src.tar.gz > > > > A staged Maven repository is available for review at: > > > https://repository.apache.org/content/repositories/orgapachecalcite-1071/org/apache/calcite/ > > > > > > Release artifacts are signed with the following key: > > https://people.apache.org/keys/committer/francischuang.asc > > https://www.apache.org/dist/calcite/KEYS > > > > N.B. > > To create the jars and test Apache Calcite Avatica: "./gradlew build > > -PskipSigning". > > > > 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.16.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.16.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: [VOTE] Release apache-calcite-avatica-1.16.0 (release candidate 0)
-1 "./gradlew build -Prelease -PskipSigning" fails on the zip when extracted. Looks like it has windows line endings and doesn't pass checks. Looks like we are publishing both tar.gz and zip now? https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.16.0-rc0/ We didn't do that in the past just the .tar.gz. I'd prefer if we removed the zip publishing and went back to just tar.gz which would alleviate the additional publishing and failing tests. Checked the following: * Commit hash passes tests with Docker and ./gradlew build -Prelease -PskipSigning * Checked signatures and hashes against tar.gz and zip * Checked passes tests from tar.gz - ./gradlew build -Prelease -PskipSigning * Checked tests in zip - this failed see above * Checked staged Maven repo is complete Kevin Risden On Sun, Dec 8, 2019 at 5:17 PM Francis Chuang wrote: > Hi all, > > I have created a build for Apache Calcite Avatica 1.16.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/204d58849ecdf2ef639308edba74f416311f7d88/site/_docs/history.md > > The commit to be voted upon: > > https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=204d58849ecdf2ef639308edba74f416311f7d88 > > Its hash is 204d58849ecdf2ef639308edba74f416311f7d88 > > Tag: > > https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=tag;h=refs/tags/avatica-1.16.0-rc0 > > The artifacts to be voted on are located here: > > https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.16.0-rc0 > (revision 37139) > > The hashes of the artifacts are as follows: > > b54066d3b67e1f47d8f3af74466155350bfa92e938f0f442383efd8abb49993c8aee3aca258a9cc2ebb347a6b2f9473c05221da52dd56971478e7989952a7393 > *apache-calcite-avatica-1.16.0-src.tar.gz > > 0739d77ad6bfebd903ddd9fb72d03540f91676ec967ea0a0941e7b428f4045b9d7dab8803c499d3d681fd9c28a79a5feeb850eadcda46055174efc5e459b3661 > *apache-calcite-avatica-1.16.0-src.zip > > A staged Maven repository is available for review at: > > https://repository.apache.org/content/repositories/orgapachecalcite-1070/org/apache/calcite/ > > Release artifacts are signed with the following key: > https://people.apache.org/keys/committer/francischuang.asc > https://www.apache.org/dist/calcite/KEYS > > N.B. > To create the jars and test Apache Calcite Avatica: "./gradlew build > -Prelease -PskipSigning". > > 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.16.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.16.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: Mutual TLS support
Based on https://issues.apache.org/jira/browse/CALCITE-2285 I think so. There is also https://calcite.apache.org/avatica/docs/security.html#custom-authentication if you wanted to do something custom. >From a quick look I don't think we have explicit steps how to set it up today. Contributions are always welcome. Kevin Risden On Thu, Nov 21, 2019 at 7:24 PM Soman Ullah wrote: > Hello, > Does Avatica support mutual TLS? If so, could someone please provide > relevant documentation on how to set it up? > > Thanks, > Somanesh >
Re: Avatica + GitHub Actions + Windows = AvaticaSpnegoTest - Principal: HTTP/stratum.antpool....@example.com is not known
> > 2019-11-10 21:29:30,443 [pool-1-thread-2] ERROR - Principal: HTTP/ > stratum.antpool@example.com is not known > 2019-11-10 21:29:30,459 [Test worker] WARN - NEGOTIATE authentication > error: No valid credentials provided (Mechanism level: No valid credentials > provided (Mechanism level: Server not found in Kerberos database (7) - > Server not found in Kerberos database)) Usually means DNS or the SPN being acquired is not correct. Should look at the test and see if it is trying to something like localhost and instead doing FQDN instead. Looks like https://github.com/apache/calcite-avatica/blob/master/server/src/test/java/org/apache/calcite/avatica/SpnegoTestUtil.java#L58 does localhost but the principal being looked up is FQDN. Kevin Risden On Sun, Nov 10, 2019 at 4:53 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Hi, > > I've added GitHub Actions for CI, and it looks like AvaticaSpnegoTest fails > again. > > The failure is the same for Maven and Gradle, so I expect it is not caused > by Gradle migration > > Maven: https://github.com/vlsi/calcite-avatica/runs/296688961#step:4:31296 > Gradle: > > https://github.com/vlsi/calcite-avatica/commit/d1bb6f04c905ed65931800cde0af6a9899e585b6/checks?check_suite_id=304254116#step:4:117 > > org.apache.calcite.avatica.AvaticaSpnegoTest > testAuthenticatedClient[0] > STANDARD_OUT > 2019-11-10 21:29:29,707 [pool-1-thread-1] INFO - The preauth data is > empty. > 2019-11-10 21:29:29,707 [pool-1-thread-1] INFO - KRB error occurred > while processing request: Additional pre-authentication required > 2019-11-10 21:29:29,785 [pool-1-thread-2] INFO - AS_REQ ISSUE: > authtime 1573421369770,cli...@example.com for krbtgt/ > example@example.com > 2019-11-10 21:29:30,443 [pool-1-thread-2] ERROR - Principal: HTTP/ > stratum.antpool@example.com is not known > 2019-11-10 21:29:30,459 [Test worker] WARN - NEGOTIATE authentication > error: No valid credentials provided (Mechanism level: No valid credentials > provided (Mechanism level: Server not found in Kerberos database (7) - > Server not found in Kerberos database)) > > org.apache.calcite.avatica.AvaticaSpnegoTest > testAuthenticatedClient[0] > FAILED > java.lang.RuntimeException: Failed to execute HTTP Request, got > HTTP/401 > at > > org.apache.calcite.avatica.remote.AvaticaCommonsHttpClientSpnegoImpl.send(AvaticaCommonsHttpClientSpnegoImpl.java:134) > at > > org.apache.calcite.avatica.remote.RemoteService.apply(RemoteService.java:34) > at > org.apache.calcite.avatica.remote.JsonService.apply(JsonService.java:172) > at > org.apache.calcite.avatica.remote.Driver.connect(Driver.java:176) > at > java.sql/java.sql.DriverManager.getConnection(DriverManager.java:677) > at > java.sql/java.sql.DriverManager.getConnection(DriverManager.java:251) > at > > org.apache.calcite.avatica.AvaticaSpnegoTest$1.run(AvaticaSpnegoTest.java:225) > at > > org.apache.calcite.avatica.AvaticaSpnegoTest$1.run(AvaticaSpnegoTest.java:223) > at java.base/java.security.AccessController.doPrivileged(Native > Method) > at java.base/javax.security.auth.Subject.doAs(Subject.java:423) > at > > org.apache.calcite.avatica.AvaticaSpnegoTest.testAuthenticatedClient(AvaticaSpnegoTest.java:223) > > Is it something known? > > PS. The failure is only for GitHub Actions + Windows. GitHub Actions macOS > test passes. > > Vladimir >
Re: [DISCUSS] Towards Avatica 1.16.0
> > To my best knowledge, the missing bits are: > * Documentation (site) update to reflect Maven -> Gradle > * Errorprone > * OWASP plugin > * "Unused dependency" > * "Used but undeclared dependency" > * Removal of pom.xml files > I'm not really sure there's a hard requirement to implement all of the > above before flipping the switch. > I'm inclined that OWASP and "unused/used dependency" can be implemented > later. Freel free to correct me. Are there Jiras to make sure these get added back in (specifically the plugins to ensure build quality(? I think Gradle can be an improvement and still learning my way around it. I know the above plugins were added (mostly by me) to ensure that code quality doesn't suffer. It would be a shame to regress since these plugins weren't added to the Gradle build at some point. Kevin Risden On Sun, Nov 10, 2019 at 2:55 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > As a follow-up, I would like to thank everybody who helped to polish the > change: Stamatis, Francis, et al. > > Vladimir >
Re: [ANNOUNCE] Haisheng Yuan joins Calcite PMC
Congrats and welcome! Kevin Risden On Mon, Nov 11, 2019 at 2:10 PM Chunhui Shi wrote: > Congratulations! > > On Mon, Nov 11, 2019 at 10:09 AM Jinfeng Ni wrote: > > > Congratulations! > > > > > > On Tue, Nov 12, 2019 at 1:23 AM Rui Wang wrote: > > > > > > Congrats HaiSheng! > > > > > > > > > -Rui > > > > > > On Mon, Nov 11, 2019 at 8:05 AM Stamatis Zampetakis > > > > wrote: > > > > > > > Congrats Haisheng! > > > > > > > > Reviews, code contributions, design discussions, helping users, and > > many > > > > more things for improving the project. > > > > > > > > Personally, I also learn a lot from our interactions. > > > > > > > > All these are much appreciated; keep it up!! > > > > > > > > Best, > > > > Stamatis > > > > > > > > On Mon, Nov 11, 2019, 4:17 PM Michael Mior wrote: > > > > > > > > > Welcome and congratulations HaiSheng! > > > > > -- > > > > > Michael Mior > > > > > mm...@apache.org > > > > > > > > > > Le dim. 10 nov. 2019 à 22:45, Francis Chuang > > > > > a écrit : > > > > > > > > > > > > I'm pleased to announce that Haisheng has accepted an invitation > to > > > > > > join the Calcite PMC. Haisheng has been a consistent and helpful > > > > > > figure in the Calcite community for which we are very grateful. > We > > > > > > look forward to the continued contributions and support. > > > > > > > > > > > > Please join me in congratulating Haisheng! > > > > > > > > > > > > - Francis (on behalf of the Calcite PMC) > > > > > > > > > > > >
Re: Snapshot jars
Latest https://builds.apache.org/job/Calcite-Promotion/ run succeeded now and looks like https://repository.apache.org/content/repositories/snapshots/org/apache/calcite/ has been updated for current modules. Kevin Risden On Wed, Oct 30, 2019 at 2:09 PM Kevin Risden wrote: > Looked at the config for the job, looks like the Calcite-Master build uses > Maven (latest). Updated the Calcite-Promotion job to match and removed the > outdated JDK 7 description. > > Kicked off a rebuild last after the config change and it is making > progress: > > https://builds.apache.org/job/Calcite-Promotion/378/ > > Kevin Risden > > > On Wed, Oct 30, 2019 at 2:04 PM Kevin Risden wrote: > >> In theory https://builds.apache.org/job/Calcite-Promotion/ should be >> based on the description of the job "Promotes SNAPSHOT builds of Calcite >> to the ASF Nexus." >> >> It looks like it has been broken for a long time (last success was July >> 2019)? >> >> Kevin Risden >> >> >> On Wed, Oct 30, 2019 at 1:49 PM Amit Chavan wrote: >> >>> Hello, >>> >>> I was wondering if the snapshot jars are being pushed to >>> https://repository.apache.org/content/repositories/snapshots >>> < >>> https://repository.apache.org/content/repositories/snapshots/org/apache/calcite/ >>> >. >>> The reason I am asking is we are building herddb with the latest Calcite >>> master and want to test it against the snapshot builds of calcite so we >>> know bug fixes that are being put in place for Calcite are working. >>> >>> Thanks, >>> Amit >>> >>
Re: Snapshot jars
Looked at the config for the job, looks like the Calcite-Master build uses Maven (latest). Updated the Calcite-Promotion job to match and removed the outdated JDK 7 description. Kicked off a rebuild last after the config change and it is making progress: https://builds.apache.org/job/Calcite-Promotion/378/ Kevin Risden On Wed, Oct 30, 2019 at 2:04 PM Kevin Risden wrote: > In theory https://builds.apache.org/job/Calcite-Promotion/ should be > based on the description of the job "Promotes SNAPSHOT builds of Calcite > to the ASF Nexus." > > It looks like it has been broken for a long time (last success was July > 2019)? > > Kevin Risden > > > On Wed, Oct 30, 2019 at 1:49 PM Amit Chavan wrote: > >> Hello, >> >> I was wondering if the snapshot jars are being pushed to >> https://repository.apache.org/content/repositories/snapshots >> < >> https://repository.apache.org/content/repositories/snapshots/org/apache/calcite/ >> >. >> The reason I am asking is we are building herddb with the latest Calcite >> master and want to test it against the snapshot builds of calcite so we >> know bug fixes that are being put in place for Calcite are working. >> >> Thanks, >> Amit >> >
Re: Snapshot jars
In theory https://builds.apache.org/job/Calcite-Promotion/ should be based on the description of the job "Promotes SNAPSHOT builds of Calcite to the ASF Nexus." It looks like it has been broken for a long time (last success was July 2019)? Kevin Risden On Wed, Oct 30, 2019 at 1:49 PM Amit Chavan wrote: > Hello, > > I was wondering if the snapshot jars are being pushed to > https://repository.apache.org/content/repositories/snapshots > < > https://repository.apache.org/content/repositories/snapshots/org/apache/calcite/ > >. > The reason I am asking is we are building herddb with the latest Calcite > master and want to test it against the snapshot builds of calcite so we > know bug fixes that are being put in place for Calcite are working. > > Thanks, > Amit >
Re: [DISCUSS] Automated security fixes via dependabot
I've been using Dependabot on my fork of a few Apache repos (including the Calcite related ones [1][2][3]) for over a year now. I had to configure dependabot to point to these repositories. It is a nice reminder of all the different dependencies that can be updated. There is also a nice link to the changelog/release notes typically so you can find out what changed. I didn't realize that Github was going to start pushing PRs. Typically I've manually looked at the list of PRs and updated the dependencies accordingly after creating a Jira like CALCITE-2789 [4]. The PRs are a good sanity check if the change will be easy or not since the tests pass/fail based on the configured Travis jobs. After committing the change, I then go back to Github and either force dependabot to rebase the PRs or wait for dependabot to notice the update and it will autoclose the stale PRs. So I am in favor of using the automated PRs in some way at least to know what is out of date. I've seen some of the PRs do large jumps in dependency version (ie: 1.x to 2.x) so automerging probably isn't the best idea (unless there is a way to tag the PR as reviewed). I've been personally taking a monthly approach to dependencies for Apache Knox where I try to once a month update dependencies. This seems to me like a reasonable tradeoff of doing dependency updates frequently but not too frequently [5] and [6]. [1] https://github.com/risdenk/calcite/pulls [2] https://github.com/risdenk/calcite-avatica/pulls [3] https://github.com/risdenk/calcite-avatica-go/pulls [4] https://issues.apache.org/jira/browse/CALCITE-2789 [5] https://issues.apache.org/jira/browse/KNOX-2009 [6] https://issues.apache.org/jira/browse/KNOX-2049 Kevin Risden On Mon, Oct 14, 2019 at 6:40 AM Francis Chuang wrote: > +1 to squashing all these changes during a release. However, my only > concern is that if upgrading the dependencies during a release breaks > something in the codebase and turns into a larger change. I think in > this case, the change should not be squashed with the other commits and > be a standalone one. > > Francis > > On 13/10/2019 4:16 pm, Julian Hyde wrote: > > I’ve not looked at the PRs but they sound useful. Keeping software > secure these days is a moving target; we have to do work just to keep up. > All of our dependencies are doing that work too, and so we need to keep up > to date with them. > > > > I think it would be useful to have a task before each release to merge > in the ones that look important. > > > > If you are concerned that this will result in many “small” changes with > no JIRA case number, the person merging the PRs could squash them into a > single commit with its own JIRA case. (I’d use 'git cherry-pick … ; git > cherry-pick ; git rebase -i origin/master’) > > > > Julian > > > > > >> On Oct 12, 2019, at 1:01 PM, Muhammad Gelbana > wrote: > >> > >> Why would we not merge those PRs or even disable the whole thing ? > >> > >> > >> > >> On Fri, Oct 11, 2019 at 12:09 AM Francis Chuang < > francischu...@apache.org> > >> wrote: > >> > >>> Dependabot is a bot on Github that opens PRs to automatically upgrade > >>> out of date dependencies to fix security issues. Recently, Github > >>> acquired dependabot and is gradually enabling the bot on all > repositories. > >>> > >>> It just opened a PR to upgrade a few dependencies in the Avatica > >>> repository: https://github.com/apache/calcite-avatica/pull/114 > >>> > >>> I'd like to start some discussion as to how we should deal with these > >>> PRs. For some background, dependency upgrades should usually have a > jira > >>> issue number assigned, so that the change is fully trackable. We > >>> recently had some discussion regarding trivial fixes to documentation > >>> and the consensus was that changes to the code is not considered to be > >>> trivial and that an issue should be filed on jira. > >>> > >>> If we will not merge these PRs, I think it makes sense to ask infra to > >>> disable them. Having these open PRs and then closing them manually seem > >>> to generate a lot of noise. According to the documentation for > >>> dependabot [1] it appears that we can either opt out of having > >>> dependabot opening PRs completely or have it open PRs. There is no > >>> middle-ground where dependabot/Github sends members of the repo a > >>> notification for security issues, but do not open any PRs. > >>> > >>> What do you guys think? > >>> > >>> Francis > >>> > >>> [1] > >>> > https://help.github.com/en/articles/configuring-automated-security-fixes > >>> > > >
Re: Github Actions for CI
So I've been wanting to sit down and look at this closer so its exciting to see progress :) Thanks for digging in. I'd be interested in looking at replacing Travis and seeing what it takes for the build with separate JVMs. One thing that would be interesting would be to move the integration > tests for Calcite to docker images and run each test for each backend in > its own job to maximize parallelism and allow each job to maximize the > available hardware resources. > I think this is a separate but related idea. It would be good to have integration tests run without a beefy VM. Definitely would simplify some of the RM steps for a release. Kevin Risden On Tue, Sep 17, 2019 at 7:20 PM Francis Chuang wrote: > A month or so ago, I started a thread on Github Actions on the list. I > have just replaced Travis with Github Actions for Avatica-Go > (CALCITE-3356). > > For the workflows in Avatica-Go (currently just 1 for CI), see: > https://github.com/apache/calcite-avatica-go/tree/master/.github/workflows > > The latest run is here: > https://github.com/apache/calcite-avatica-go/runs/226087805 > > The VMs provided by Github are a lot beefier (2 core CPUs, 7GB RAM, 14GB > SSD disk). The tests are slightly slower compare to Travis (in the order > of seconds), but this is most likely due to us having to check out the > code during run time and the need to compile the Github Action for > checking out the code for each run. I don't think this is too much of an > issue and the direct integration with Github is much nicer. > > I think it shouldn't be too difficult to move Avatica and Calcite over. > We can probably get rid of Appveyor as well since Github Actions > provides Windows and OS X nodes as well. > > One thing that would be interesting would be to move the integration > tests for Calcite to docker images and run each test for each backend in > its own job to maximize parallelism and allow each job to maximize the > available hardware resources. > > Francis >
Re: Re: [ANNOUNCE] New committer: Julian Feinauer
Congrats and welcome Julian! Kevin Risden On Wed, Sep 18, 2019 at 4:12 PM Muhammad Gelbana wrote: > Welcome aboard ! > > Thanks, > Gelbana > > > On Wed, Sep 18, 2019 at 5:10 PM Andrei Sereda wrote: > > > Congratulations, Julian ! > > > > On Tue, Sep 17, 2019 at 11:26 PM Amit Chavan wrote: > > > > > Congrats, Julian !! > > > > > > On Tue, Sep 17, 2019 at 8:12 PM XING JIN > > wrote: > > > > > > > Congrats, Julian ! > > > > You are well deserved ~ > > > > > > > > Haisheng Yuan 于2019年9月18日周三 上午10:38写道： > > > > > > > > > Congrats, Julian! > > > > > > > > > > - Haisheng > > > > > > > > > > -- > > > > > 发件人：Chunwei Lei > > > > > 日 期：2019年09月18日 10:30:31 > > > > > 收件人： > > > > > 主 题：Re: [ANNOUNCE] New committer: Julian Feinauer > > > > > > > > > > Congratulations, Julian! > > > > > > > > > > > > > > > > > > > > Best, > > > > > Chunwei > > > > > > > > > > > > > > > On Wed, Sep 18, 2019 at 9:24 AM Danny Chan > > > wrote: > > > > > > > > > > > Congratulations, Muhammad ! Welcome to join us ! Thanks for your > > huge > > > > > > contribution for the Match Recognize. > > > > > > > > > > > > Best, > > > > > > Danny Chan > > > > > > 在 2019年9月18日 +0800 AM5:55，Francis Chuang < > francischu...@apache.org > > > > >，写道： > > > > > > > Apache Calcite's Project Management Committee (PMC) has invited > > > > Julian > > > > > > > Feinauer to become a committer, and we are pleased to announce > > that > > > > he > > > > > > > has accepted. > > > > > > > > > > > > > > Julian is an active contributor to the Calcite code base and > has > > > been > > > > > > > active on the mailing list answering questions, participating > in > > > > > > > discussions and voting for releases. > > > > > > > > > > > > > > Julian, welcome, thank you for your contributions, and we look > > > > forward > > > > > > > your further interactions with the community! If you wish, > please > > > > feel > > > > > > > free to tell us more about yourself and what you are working > on. > > > > > > > > > > > > > > Francis (on behalf of the Apache Calcite PMC) > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [ANNOUNCE] New committer: Muhammad Gelbana
Congrats and welcome Muhammad! Kevin Risden On Wed, Sep 18, 2019 at 12:15 PM Muhammad Gelbana wrote: > Thank you all for the very warm welcome. > > Calcite really changed a lot of things for my current employer. I got to > know Calcite when I was exposed to Drill and now we're planning to > integrating Calcite within our product. Being an analytics company, Calcite > provides great deal of help to us. > > Thanks, > Gelbana > > > On Wed, Sep 18, 2019 at 5:10 PM Andrei Sereda wrote: > > > Congrats, Muhammad! > > > > On Tue, Sep 17, 2019 at 11:26 PM Amit Chavan wrote: > > > > > Congratulations, Muhammad !! > > > > > > On Tue, Sep 17, 2019 at 8:10 PM XING JIN > > wrote: > > > > > > > Congrats, Muhammad ! > > > > > > > > 王炎林 <1989yanlinw...@163.com> 于2019年9月18日周三 上午10:38写道： > > > > > > > > > Congratulations, Muhammad! > > > > > > > > > > > > > > > Best, > > > > > Yanlin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 2019-09-18 05:58:53, "Francis Chuang" > > > > > wrote: > > > > > >Apache Calcite's Project Management Committee (PMC) has invited > > > Muhammad > > > > > >Gelbana to become a committer, and we are pleased to announce that > > he > > > > > >has accepted. > > > > > > > > > > > >Muhammad is an active contributor and has contributed numerous > > patches > > > > > >to Calcite. He has also been extremely active on the mailing list, > > > > > >helping out new users and participating in design discussions. > > > > > > > > > > > >Muhammad, welcome, thank you for your contributions, and we look > > > forward > > > > > >your further interactions with the community! If you wish, please > > feel > > > > > >free to tell us more about yourself and what you are working on. > > > > > > > > > > > >Francis (on behalf of the Apache Calcite PMC) > > > > > > > > > > > > > > >
Re: [VOTE] Calcite logo selection
Vote 5B Kevin Risden On Fri, Jun 28, 2019 at 12:19 PM Haisheng Yuan wrote: > Vote for 5B. > > > > > > Thanks~ > Haisheng > Yuan-- > 发件人：Michael Mior > 日 期：2019年06月28日 21:28:25 > 收件人： > 主 题：[VOTE] Calcite logo selection > > Based on the previous thread[0], many have weighed in on their > preference. There were two clear front runners which we will now vote > on. The vote will be open for 72 hours. Keep in mind that we can still > discuss some smaller changes such as font, color, etc. with whatever > logo is selected. > > The two alternatives are below: > > https://github.com/zabetak/calcite/blob/calcite-logo/site/img/index.md#candidate-5b > > https://github.com/zabetak/calcite/blob/calcite-logo/site/img/index.md#candidate-2c > > I'm not currently placing a vote since I really can't decide between > the two. But I like both much better than the current logo. Thanks to > all who contributed a design! > > [0] > https://mail-archives.apache.org/mod_mbox/calcite-dev/201906.mbox/%3C8587ADCD-FF19-4486-98C1-4B645614FB47%40apache.org%3E > -- > Michael Mior > mm...@apache.org >
Re: Release 1.20 and release notes
Top level has src/ which has a bunch of config files for checkstyle/forbidden-apis/etc. Might be a decent spot. Kevin Risden On Wed, Jun 26, 2019 at 11:07 AM Michael Mior wrote: > A Gradle task is great if we migrate to Gradle, but I don't think it's > a compelling reason in itself. I would personally prefer to just have > a copy of the script somewhere in the repo because the only purpose of > putting it in the HOWTO would be so someone could copy and paste and > run it. That said, I'm not sure where a good spot for such scripts to > live would be in the folder hierarchy. > -- > Michael Mior > mm...@apache.org > > Le mar. 25 juin 2019 à 16:23, Julian Hyde a écrit : > > > > Or just paste the script into HOWTO. > > > > It works fine on macOS, Linux and Windows/Cygwin, which I think covers > it. > > > > Julian > > > > > > > On Jun 25, 2019, at 1:19 PM, Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > > > > > > Michael>If we're going to use it, I think we > > > Michael>might as well have a copy in the Calcite repo. > > > > > > I have a plan here: > > > 1) We migrate to Gradle > > > 2) The script can be written as a Gradle task so it is easily > available, > > > and it works in all OSes > > > > > > Vladimir > > >
Re: Rejected commits to master
I think there have been some delays syncing between github and gitbox. I think it depends which origin you are pointing at and which commit is there. Since both github and gitbox are masters, we can actually push to either one and I would guess there is some checks to make sure commits don't have issues but a pull might be slightly out of date? Kevin Risden On Wed, May 22, 2019 at 5:12 PM Julian Hyde wrote: > I pushed a commit to the master branch this morning and it was > rejected due to an intervening commit from Laurent. But that > intervening commit did not appear when I did 'git fetch origin'. > > Just now, I was just able to push successfully. In both cases I used > 'git push origin master' from the command line, without the '-f' > (force) flag. > > You can see that both commits generated emails: [1] [3]. Laurent's > intervening commit also generated an email: [2]. > > All, Has anyone else seen this behavior? > > Laurent, What command did you use to commit? > > Julian > > [1] > https://lists.apache.org/thread.html/ac70079b65305a9040bfe2ed0720768343d2f6dc038b9a63c081ff0b@%3Ccommits.calcite.apache.org%3E > > [2] > https://lists.apache.org/thread.html/bddfd2ad8cbe3148820b334b1554fae23d4e05a2b00967b71e5d7191@%3Ccommits.calcite.apache.org%3E > > [3] > https://lists.apache.org/thread.html/335c042be3fbd042f327e9742d45de790d731d8a7f883294dacf9322@%3Ccommits.calcite.apache.org%3E >
Re: [VOTE] Release apache-calcite-avatica-go-4.0.0 (release candidate 1)
+1 (binding) macOS 10.14.3 * Checked hashes and signatures * Release notes look good * Tests run in docker for both git hash and tar.gz Kevin Risden On Tue, May 14, 2019 at 5:07 AM Stamatis Zampetakis wrote: > Windows 10 Pro, jdk1.8.0_202, Docker Community 18.09.2 > * Checked signatures and checksums OK > * Went over release note OK > * Run tests (docker-compose run test) on git repo OK > > (Minor comment) I noticed that in the release note there is (at least) an > entry (i.e., CALCITE-3024) where the description does not match exactly the > Jira summary or the commit message. > Since there are also cases that the commit message is not the same with the > Jira summary, I was wondering (mostly for future releases) what we are > supposed to put in the release note. > Let's discuss this if necessary in a separate thread. > > +1 (binding) > > On Sun, May 12, 2019 at 2:04 PM Francis Chuang > wrote: > > > Hi all, > > > > I have created a release for Apache Calcite Avatica Go 4.0.0, release > > candidate 1. > > > > Thanks to everyone who has contributed to this release. The release > > notes are available here: > > > > > https://github.com/apache/calcite-avatica-go/blob/3790ef528d63d9c274114f8d21fc6c6003ef8bcf/site/_docs/go_history.md > > > > The commit to be voted on: > > > > > https://gitbox.apache.org/repos/asf?p=calcite-avatica-go.git;a=commit;h=3790ef528d63d9c274114f8d21fc6c6003ef8bcf > > > > The hash is 3790ef528d63d9c274114f8d21fc6c6003ef8bcf > > > > The artifacts to be voted on are located here: > > > > > https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-go-4.0.0-rc1/ > > > > The hashes of the artifacts are as follows: > > src.tar.gz FDDFD5F8 6386A748 5308532A 56CD2836 220E2CE8 A00955DC > > 6E5E9315 45813C57 4B03FA1C 17008C19 981C07EE 4CAC9391 2CFEB06C DDBA8D9A > > F1E36218 03C46063 > > > > Release artifacts are signed with the following key: > > https://people.apache.org/keys/committer/francischuang.asc > > > > Instructions for running the test suite is located here: > > > > > https://github.com/apache/calcite-avatica-go/blob/3790ef528d63d9c274114f8d21fc6c6003ef8bcf/site/develop/avatica-go.md#testing > > > > Please vote on releasing this package as Apache Calcite Avatica Go 4.0.0. > > > > To run the tests without a Go environment, install docker and > > docker-compose. Then, in the root of the release's directory, run: > > docker-compose run test > > > > When the test suite completes, run "docker-compose down" to remove and > > shutdown all the containers. > > > > 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 Avatica Go 4.0.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: [ANNOUNCE] New committer: Danny Chan
Welcome and congrats! Kevin Risden On Tue, May 14, 2019 at 1:27 AM Lin Li wrote: > Congratulations, Danny! > > Best, > Lincoln > > Jark Wu 于2019年5月14日周二 上午10:05写道： > > > Congratulations Danny! > > > > Best, > > Jark > > > > On Tue, 14 May 2019 at 09:57, Yuzhao Chen wrote: > > > > > Thank you everyone for your kind messages. > > > > > > Currently I am working in Alibaba Blink SQL Engine team in Hangzhou, > > > Zhejiang, China. We are developing a production version of Apache > Flink. > > > Our team has done many promotions for flink-table module and recently > we > > > are merging and contributing our codebase to the Apache Flink > community. > > > > > > It is my honor to be part of Apache Calcite community, I will > contribute > > > continuously to this great project. > > > > > > Best, > > > Danny Chan > > > 在 2019年5月14日 +0800 AM6:40，Francis Chuang >，写道： > > > > Apache Calcite's Project Management Committee (PMC) has invited Danny > > > > Chan to become a committer, and we are pleased to announce that he > has > > > > accepted. > > > > > > > > Danny has been a prolific contributor to Calcite, with CALCITE-2969 > > > > being one of his more complex contributions to date. He has also been > > > > extremely active on our mailing lists, contributing to many design > > > > discussions. > > > > > > > > Danny, welcome, thank you for your contributions, and we look forward > > > > your further interactions with the community! If you wish, please > feel > > > > free to tell us more about yourself and what you are working on. > > > > > > > > Francis (on behalf of the Apache Calcite PMC) > > > > > >
Re: [VOTE] Release apache-calcite-avatica-1.15.0 (release candidate 0)
+1 * Checked signatures and hashes * Ran tests from git commit and tar on OpenJDK 1.8 Kevin Risden On Fri, May 10, 2019 at 4:21 AM Hongze Zhang wrote: > +1 > > (OpenJDK 1.8, Fedora 29) > * Built and run tests from tarball [OK] > * Built and run tests from Git commit 95e154 [OK] > * Run Calcite tests with the RC [OK] > * Run some smoke tests with SQLLine, DBeaver [OK] > * Checked signatures and hashes [OK] > > Thanks Francis! > > Hongze > > -- Original Message -- > From: "Andrew Pilloud" > To: dev@calcite.apache.org > Sent: 2019/5/10 0:10:05 > Subject: Re: [VOTE] Release apache-calcite-avatica-1.15.0 (release > candidate 0) > > >+1 > > > >Tested with Apache Beam, all tests pass. Also tested error messages with > >SqlLine, SQL Workbench/J, and SQuirreL SQL. > > > >Thanks for the quick turnaround! > > > >Andrew > > > >*From: *Francis Chuang > >*Date: *Thu, May 9, 2019 at 2:35 AM > >*To: * > > > >Hi all, > >> > >> I have created a build for Apache Calcite Avatica 1.15.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.15/site/_docs/history.md > >> > >> The commit to be voted upon: > >> > >> > https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=95e15456e4b16f1a51b0e86babb113114c9b62d0 > >> > >> Its hash is 95e15456e4b16f1a51b0e86babb113114c9b62d0 > >> > >> The artifacts to be voted on are located here: > >> > >> > https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.15.0-rc0/ > >> > >> The hashes of the artifacts are as follows: > >> src.tar.gz.sha512 > >> > >> > 1d75990eb77f1123ecdafb21f004719383b396fab84cb8aa4a773e9fe57fa7adc1cdd0b31285e74e90cdaa84f3c00249da50e74d9510403e51f07f4bbe21d7dc > >> > >> A staged Maven repository is available for review at: > >> > https://repository.apache.org/content/repositories/orgapachecalcite-1060 > >> > >> 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.15.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: [RESULT] [VOTE] Release apache-calcite-avatica-1.14.0 (release candidate 0)
Little late but +1 thanks Francis! Kevin Risden On Mon, Apr 29, 2019 at 3:00 AM Yuzhao Chen wrote: > Thx for your work, Francis > > Best, > Danny Chan > 在 2019年4月29日 +0800 PM1:56，Francis Chuang ，写道： > > Thanks to everyone who has tested the release candidate and given > > their comments and votes. > > > > The tally is as follows. > > > > 3 binding +1s: > > Francis Chuang > > Michael Mior > > Stamatis Zampetakis > > > > 1 non-binding +1s: > > Haisheng Yuan > > > > No 0s or -1s. > > > > Therefore I am delighted to announce that the proposal to release > > Apache Calcite Avatica 1.14.0 has passed. > > > > Thanks everyone. We’ll now roll the release out to the mirrors. > > > > Francis >
Re: Clean up JIRA tickets
You can do this as a bulk transition to avoid emailing everyone of the change. If you select "Tools" -> "Bulk change". Kevin Risden On Mon, Apr 29, 2019 at 10:46 AM Hongze Zhang wrote: > Hi all, > > As I have suggested on a related thread[1] started by Stamatis, I am > planning to close the JIRA tickets that are marked as status "RESOLVED" but > bound with an earlier fix version. Say, if a ticket is marked "RESOLVED", > and its fix version is provided but not one of our unreleased versions > 1.20.0/1.21.0/avatica-1.15.0/avatica-go-4.0.0/avatica-go-5.0.0, it is going > to be closed. > > Here is a link to the full list (currently 78 tickets in total): > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20CALCITE%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20not%20in%20(1.20.0%2C1.21.0%2Cavatica-1.15.0%2Cavatica-go-4.0.0%2Cavatica-go-5.0.0) > > I'll close them by the ascending order of JIRA ID respectively. If you > used to participate in the discussion of any issue on the list, and you > think it is too early to close, please feel free to reopen and add some > follow-up comments. > > Thanks, > Hongze > > > [1] > https://lists.apache.org/thread.html/03f1e1937892e2ccbb30b639219122c28ca3c389e10aa01ed2214ca1@%3Cdev.calcite.apache.org%3E >
Re: [ANNOUNCE] New committers: Zhiwei Peng
Congrats and welcome! Kevin Risden On Sat, Apr 27, 2019 at 11:44 AM Stamatis Zampetakis wrote: > Congratulations Zhiwei! > > With so many high quality contributions there is nothing left to say. Well > deserved! > > On Sat, Apr 27, 2019 at 6:14 AM Chunwei Lei > wrote: > > > Congratulations, Zhiwei! > > > > > > > > Best, > > Chunwei > > > > On Sat, Apr 27, 2019 at 12:13 PM Yuzhao Chen > wrote: > > > > > > Congratulations, Zhiwei! > > > > > > Best, > > > Danny Chan > > > 在 2019年4月27日 +0800 AM10:37，Francis Chuang >，写道： > > > > Apache Calcite's Project Management Committee (PMC) has invited > Zhiwei > > > > Peng to become a committer, and we are pleased to announce that he > has > > > > accepted. > > > > > > > > Zhiwei has been contributing to Calcite for a while, racking up an > > > > impressive 20 pull requests, in particular, doing a lot of work to > > > > improve RexSimplify. > > > > > > > > Zhiwei, welcome, thank you for your contributions, and we look > forward > > > > your further interactions with the community! If you wish, please > feel > > > > free to tell us more about yourself and what you are working on. > > > > > > > > Francis (on behalf of the Apache Calcite PMC) > > >
Re: [ANNOUNCE] New committers: Chunwei Lei
Congrats and welcome! Kevin Risden On Sat, Apr 27, 2019 at 11:36 AM Stamatis Zampetakis wrote: > It's great to have you onboard Chunwei! > > I would love to see some those of optimizations land in Calcite. > > Great work so far, keep it up :) > > On Sat, Apr 27, 2019 at 4:39 PM Chunwei Lei > wrote: > > > Thank you all for the warm welcome! > > > > I am currently working at optimizer team of Alibaba MaxCompute which > > uses Calcite > > for cost-based query optimization. In the past few months, I have been > > focusing on > > reducing optimization latency including reducing rule attempts, > > introducing plan cache > > and so on. > > > > It is my great honor to become a committer of Apache Calcite and I > > will do my best to > > make more contributions. > > > > > > Best, > > Chunwei > > > > On Sat, Apr 27, 2019 at 12:05 PM Yuzhao Chen > wrote: > > > > > > Congratulations, Chunwei! > > > > > > Best, > > > Danny Chan > > > 在 2019年4月27日 +0800 AM11:04，Haisheng Yuan ，写道： > > > > Congratulations, Chunwei! > > > > > > > > Thanks ~ > > > > Haisheng Yuan > > > > -- > > > > 发件人：Francis Chuang > > > > 日 期：2019年04月27日 10:34:43 > > > > 收件人： > > > > 主 题：[ANNOUNCE] New committers: Chunwei Lei > > > > > > > > Apache Calcite's Project Management Committee (PMC) has invited > Chunwei > > > > Lei to become a committer, and we are pleased to announce that he has > > > > accepted. > > > > > > > > Over the past few months, Chunwei has proposed numerous pull > requests, > > > > reviewed PRs and opened JIRA issues for the project. > > > > > > > > Chunwei, welcome, thank you for your contributions, and we look > forward > > > > your further interactions with the community! If you wish, please > feel > > > > free to tell us more about yourself and what you are working on. > > > > > > > > Francis (on behalf of the Apache Calcite PMC) > > >
Re: [ANNOUNCE] Stamatis Zampetakis joins Calcite PMC
Congrats Stamatis! Kevin Risden On Sat, Apr 27, 2019 at 12:13 AM Yuzhao Chen wrote: > Congrats, Stamatis. And thx for your help ! > > Best, > Danny Chan > 在 2019年4月27日 +0800 AM10:44，dev@calcite.apache.org，写道： > > > > Congrats, Stamatis. Thanks for your good work. >
Re: [ANNOUNCE] New committers: Ruben Quesada Lopez
Congrats and welcome! Kevin Risden On Sat, Apr 27, 2019 at 1:48 PM Ruben Q L wrote: > Thank you everyone for your kind messages. > > Currently I am working with Stamatis in the Core Engine team at TIBCO > (formerly Orchestra Networks) in Paris, France. We are developing a new > Calcite-based Query Execution Framework for our product TIBCO EBX. > > It is an honor to be part of this community, I will do my best to > contribute to the project. > > Best regards, > Ruben Q. L. > > > Le sam. 27 avr. 2019 à 18:00, Stamatis Zampetakis a > écrit : > > > Congrats Ruben! > > > > It's been a pleasure working with you. > > > > Looking forward to see recursive queries and many more great > contributions > > in Calcite. > > > > > > On Sat, Apr 27, 2019 at 6:14 AM Chunwei Lei > > wrote: > > > > > Congratulations, Ruben! > > > > > > > > > > > > Best, > > > Chunwei > > > > > > On Sat, Apr 27, 2019 at 12:06 PM Yuzhao Chen > > wrote: > > > > > > > > Congratulations, Ruben, and thx for your work! > > > > > > > > Best, > > > > Danny Chan > > > > 在 2019年4月27日 +0800 AM10:57，Haisheng Yuan >，写道： > > > > > Congratulations, Ruben! I am impressed by your contributions. > > > > > > > > > > Thanks ~ > > > > > Haisheng Yuan > > > > > -- > > > > > 发件人：Francis Chuang > > > > > 日 期：2019年04月27日 10:39:18 > > > > > 收件人： > > > > > 主 题：[ANNOUNCE] New committers: Ruben Quesada Lopez > > > > > > > > > > > > > > > Apache Calcite's Project Management Committee (PMC) has invited > Ruben > > > > > Quesada Lopez to become a committer, and we are pleased to announce > > > that > > > > > he has accepted. > > > > > > > > > > In just a few months, Ruben has contributed more than 15 pull > > requests > > > > > to the project, fixing bugs and implementing new features. > > > > > > > > > > Ruben, welcome, thank you for your contributions, and we look > forward > > > > > your further interactions with the community! If you wish, please > > feel > > > > > free to tell us more about yourself and what you are working on. > > > > > > > > > > Francis (on behalf of the Apache Calcite PMC) > > > > > >
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 > > > > > > >
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
[jira] [Created] (CALCITE-2983) Add Avatica compatibility page for TLS and IBM Java
Kevin Risden created CALCITE-2983: - Summary: Add Avatica compatibility page for TLS and IBM Java Key: CALCITE-2983 URL: https://issues.apache.org/jira/browse/CALCITE-2983 Project: Calcite Issue Type: Task Components: avatica Reporter: Kevin Risden With the Jetty upgrade in CALCITE-2972, there are some compatibility issues between TLS support and IBM Java. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2972) Upgrade jetty to 9.4.15.v20190215
Kevin Risden created CALCITE-2972: - Summary: Upgrade jetty to 9.4.15.v20190215 Key: CALCITE-2972 URL: https://issues.apache.org/jira/browse/CALCITE-2972 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Kevin Risden Assignee: Kevin Risden Fix For: avatica-1.14.0 Avatica should be upgraded to the latest Jetty 9.4.15.v20190215 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [DISCUSS] Automated website builds for Calcite projects
As far as I know Jenkins builds.apache.org is self service. You should be able to login with your Apache LDAP credentials. Can definitely modify jobs there for other projects and create new ones. The Calcite jobs on builds.apache.org are configured in the Jenkins UI. There is no Jenkinsfile for Calcite projects currently. Some other projects have looked at using Jenkinsfiles. Some details are here [1]. [1] https://cwiki.apache.org/confluence/display/INFRA/Multibranch+Pipeline+recipies Kevin Risden On Mon, Apr 1, 2019 at 8:11 AM Michael Mior wrote: > I'm not sure how the builds were set up initially, but AFAIK all the > configuration is in the control panel nd not in the repo. Would be > great to have this automated :) > > -- > Michael Mior > mm...@apache.org > > Le dim. 31 mars 2019 à 19:07, Francis Chuang > a écrit : > > > > While moving the website repo from SVN to Git a while back, I briefly > > mentioned the possibility of automating our website builds, so that we > > do not need to manually push the built website assets. > > > > I have done some research regarding ASF's build infrastructure and it > > turns out there is a git-website jenkins node for doing this. > > Unfortunately, there isn't much documentation for this, and the howto > > for this appears to be work in progress: > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75964385 > > > > Before reaching out to infra and builds I'd like to clarify my > > understanding of how Jenkins builds are currently set up for Calcite, > > before asking builds and infra for further assistance: > > > > - How were the Jenkins builds set up initially? Did INFRA set this up > > for us or was there a self-service system? > > > > - Are the ASF builds configured using exclusively using the control > > panel at https://builds.apache.org/job/Calcite-Master/ or do we have > > other configurations in the repository using configuration files similar > > to .travis.yml? > > > > Francis >
Re: [DISCUSS] Towards Avatica 1.14.0
> > Kevin: Do you think these can make it into the release? > - https://github.com/apache/calcite-avatica/pull/28 > - https://github.com/apache/calcite-avatica/pull/36 I think both of the above are real bugs sadly. I have not tracked down what the solutions are. I think both are up for grabs if someone wants to try to fix them. I opened the PRs to show the issues not necessarily the solution. I probably won't have time to get them into this release. Kevin Risden On Thu, Mar 28, 2019 at 5:41 PM Francis Chuang wrote: > Would anyone be interested in finishing CALCITE-2322 > (https://github.com/apache/calcite-avatica/pull/49)? > > There were some minor changes that were requested, but the original > author has disappeared. There does not appear to be any tests for the > change, but I am not sure how much work is required to finish the PR. > > A few comments about the other PRs: > - https://github.com/apache/calcite-avatica/pull/89 has been updated and > is ready for review > - https://github.com/apache/calcite-avatica/pull/86 is ready for review, > but might require more investigation > - https://github.com/apache/calcite-avatica/pull/85 no tests, but maybe > the change is not easy to test? > > Kevin: Do you think these can make it into the release? > - https://github.com/apache/calcite-avatica/pull/28 > - https://github.com/apache/calcite-avatica/pull/36 > > Francis > > On 27/03/2019 1:03 pm, Yuzhao Chen wrote: > > Thx for your work Francis, the PRs are not too many, I think the > timeline is ok. > > > > Best, > > Danny Chan > > 在 2019年3月27日 +0800 AM5:19，Francis Chuang ，写道： > >> I am currently planning to make rc0 available for voting next Friday (5 > >> April 2019). How does this sound? Does this leave enough time for PRs to > >> get reviewed and other changes to be committed? > >> > >> If the proposed timeline is too tight, please let me know. > >> > >> Francis > >> > >> On 26/03/2019 8:54 am, Julian Hyde wrote: > >>> Thank you for stepping up! The release process - especially for > Calcite, but also for Avatica and Avatica-Go - seems to be getting heavier > these days, and it seems to be good to keep up momentum. > >>> > >>> I’ll review two or three of those PRs. I hope some other committers > will step forward and take a few. > >>> > >>> Julian > >>> > >>> > >>>> On Mar 25, 2019, at 2:43 PM, Francis Chuang > wrote: > >>>> > >>>> Hey all, > >>>> > >>>> Now that Kevin has finalized Calcite 1.19.0, I want to talk about > Avatica.The last release of Avatica was around 4 months ago and I am happy > to be release manager for 1.14.0. > >>>> > >>>> There are around 10 unreleased commits and 6 pretty fresh PRs that I > want to get into this release: > >>>> - https://github.com/apache/calcite-avatica/pull/82 > >>>> - https://github.com/apache/calcite-avatica/pull/85 > >>>> - https://github.com/apache/calcite-avatica/pull/86 > >>>> - https://github.com/apache/calcite-avatica/pull/88 > >>>> - https://github.com/apache/calcite-avatica/pull/89 > >>>> - https://github.com/apache/calcite-avatica/pull/90 > >>>> > >>>> If anyone has spare cycles to review these PRs, please review them, > so we can get them in. > >>>> > >>>> I would like to get 1.14.0 out before the next Calcite release, so > that Calcite can use 1.14.0. Are there any others issues you guys would > like to be fixed? > >>>> > >>>> Once Avatica 1.14.0 is released, I will follow it with a release of > Avatica-Go. > >>>> > >>>> Francis > >>> > > >
[jira] [Created] (CALCITE-2961) Enable Travis to test against JDK 13
Kevin Risden created CALCITE-2961: - Summary: Enable Travis to test against JDK 13 Key: CALCITE-2961 URL: https://issues.apache.org/jira/browse/CALCITE-2961 Project: Calcite Issue Type: Improvement Components: build Reporter: Kevin Risden Assignee: Kevin Risden Fix For: avatica-1.14.0, 1.20.0 The docker hub Maven image recently added support for JDK 13. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Site branch
Sorry for messing up the site branch as part of the 1.19.0 release. I think I missed the fast forward flag on the merge. Thanks to all for cleaning it up. +1 to Francis' suggestion to make the site docs more clear. I think that was the hardest part of the release. I'll try to set some time aside to type up some notes on the process. Kevin Risden On Wed, Mar 27, 2019 at 7:17 PM Francis Chuang wrote: > +1 To Julian's amendment. Thanks for sorting this out, Julian + Stamatis. > > The release process for Calcite is quite involved and can be somewhat > complex. I think we should consider adding explicit instructions to the > HOWTO document with the exact git commands need to even the site and > master branches after the finalization of a release. > > The current instructions just say to do a fast-forward merge from the > release branch back to master. > > I think the addition would be immensely helpful for future RMs (I > believe the next few RMs for Calcite have not made a Calcite release > before, previously). > > On 28/03/2019 10:13 am, Michael Mior wrote: > > LGTM. Thanks for sorting this out! > > -- > > Michael Mior > > mm...@apache.org > > > > Le mer. 27 mars 2019 à 19:12, Julian Hyde a écrit : > >> > >> I saw that Stamatis just did “git push origin a9687de81:site”. That’s > somewhat of an improvement, because it removes the merge commit, but it > introduces a problem: it includes “25ffeb4ac [CALCITE-2908] Implement SQL > LAST_DAY function”, and that commit updates the site with a function that > will not be in the product until 1.20. > >> > >> I’m just about to push 42dce0928. That commit contains only commits > that change the site, cherry-picked from master. I hope people view that as > an improvement. > >> > >> Julian > >> > >> $ git log --graph --abbrev-commit --pretty=oneline site origin/site -- > >> * 42dce0928 - (HEAD -> site) Site: Add Alibaba MaxCompute to po > >> * 1939f9c68 - Suppress deprecation warning, and remove unicode > >> * 819722500 - Site: Add new committers (Haisheng Yuan, Hongze Z > >> * a5530e5fb - [CALCITE-2952] Add JDK 12 as tested to 1.19.0 his > >> | * a9687de81 - (origin/site, origin/master) [CALCITE-2958] Upg > >> | * 650d24b9a - Site: Add Alibaba MaxCompute to powered-by page > >> | * ddbcd3955 - Suppress deprecation warning, and remove unicod > >> | * 1f4b61989 - [CALCITE-2796] JDBC adapter should convert 'GRO > >> | * 4fdf241df - In RelFieldCollation, add a "withX" copy method > >> | * 90e69d418 - [CALCITE-2953] LatticeTest.testTileAlgorithm2 a > >> | * 11c067f99 - Site: Add new committers (Haisheng Yuan, Hongze > >> | * 35ab6c768 - [CALCITE-2952] Add JDK 12 as tested to 1.19.0 h > >> | * 1b430721c - [CALCITE-574] Remove org.apache.calcite.util.Bu > >> | * 81143c830 - [CALCITE-589] Extend unifyAggregates method to > >> | * 25ffeb4ac - [CALCITE-2908] Implement SQL LAST_DAY function > >> |/ > >> * 406129b97 - [CALCITE-2951] Support decorrelate subquery that > >> * 2fa7fd79b - [CALCITE-2946] RelBuilder wrongly skips creation > >> * ecc100ea2 - [CALCITE-2943] Materialized view rewriting logic > >> * 79f432457 - [CALCITE-2942] Materialized view rewriting logic > >> * 06b1894db - Site: News item for release 1.19.0 (2 days ago) < > >> * b8f4edfcf - (origin/branch-1.19) [maven-release-plugin] prepa > >> > >> > >> > >> > >>> On Mar 27, 2019, at 3:57 PM, Haisheng Yuan > wrote: > >>> > >>> +1 > >>> > >>> > >>> > >>> > >>> > >>> Thanks~ > >>> Haisheng > Yuan-- > >>> 发件人：Francis Chuang > >>> 日 期：2019年03月28日 06:49:44 > >>> 收件人： > >>> 主 题：Re: Site branch > >>> > >>> +1 I think this should reduce the number of "commits ahead" in the site > >>> branch compared to master to 0. > >>> > >>> On 28/03/2019 9:46 am, Julian Hyde wrote: > >>>> The site branch currently has a merge commit in it. But traditionally > after a release the site branch points to the same commit as the master > branch. > >>>> > >>>> So, any objections if I reset the site branch, as follows: > >>>> > >>>> $ git checkout site > >>>> $ git reset —hard origin/branch-1.19 > >>>> $ git push -f origin site > >>>> > >>>> Then cherry-pick a couple of commits from master that need to go into > the site. > >>>> > >>>> To my eyes at least, that creates a simpler & clearer history. > >>>> > >>>> Julian > >>>> > >>>> > >> >
Re: [DISCUSS] Towards Calcite 1.19.0
Maybe I screwed something up by cherry picking 27706dd078049601ea26cef7c45a95046719c444 into site branch? I didn't want to remerge master again. Since just needed that one commit on the site branch. According to the site readme, I thought we only had to cherry-pick commits to the site branch between releases. Kevin Risden On Tue, Mar 26, 2019 at 7:57 PM Stamatis Zampetakis wrote: > Thanks again Kevin. > > Regarding the differences between the master and the site it seems that > something is off. > > I think that it is normal to be 10 commits behind master since from the > time that master was merged into site there have been 10 commits on the > master. > > On the other hand the 7 commits ahead is bit weird. Normally, it should be > 3 I think (only those made after the merge of master into site). > > By doing > > git log master..site > > I get the following which shows that some commits exist in the site but not > in the master. > > commit d09ea01b8c79dd162c40ad4bc0dc7f2d9ae18214 (HEAD -> site, > upstream-apache/site) > Author: Francis Chuang > Date: Wed Mar 27 08:54:49 2019 +1100 > > Site: Add new committers (Haisheng Yuan, Hongze Zhang and Stamatis > Zampetakis) > > commit 27706dd078049601ea26cef7c45a95046719c444 > Author: > Kevin Risden > > Date: Mon Mar 25 08:37:23 2019 -0400 > > Site: News item for release 1.19.0 > > commit 3ac7039292501293aec8dd953545a397acefe2a4 > Merge: a96db9117 b8f4edfcf > Author: Kevin Risden > Date: Mon Mar 25 10:43:10 2019 -0400 > > Merge branch 'master' into site > > commit a96db9117e45ea32a953dc96d2db7e04f66765c6 > Author: Andrei Sereda <25229979+asereda...@users.noreply.github.com> > Date: Fri Jan 25 15:28:22 2019 -0500 > > Site: [CALCITE-2734] Update mongo documentation to reflect filename > changes > > After mongo adapter refactoring some files were renamed (eg. > `mongo-zips-model.json` > -> `mongo-models.json` in `test/resources`). > > commit d561dba0e090aed361b416978944a5a46a410071 > Author: Stamatis Zampetakis > Date: Tue Jan 8 16:01:48 2019 +0100 > > Site: Add commit message guidelines for contributors (Stamatis > Zampetakis) > > Add guidelines for commit messages proposed by Julian Hyde in various > discussions in the dev list. > > commit 15a6d384f8b08ca5fb7288d624fa555e0f44f4ab > Author: Francis Chuang > Date: Thu Jan 10 08:48:15 2019 +1100 > > Site: Add Zoltan Haindrich as committer > > commit 2afea1fc94c5cda594535f5d194b86f723e2e8be > Author: Andrei Sereda <25229979+asereda...@users.noreply.github.com> > Date: Thu Jan 3 11:33:36 2019 -0500 > > Site: Elastic query example on _MAP > > Στις Τρί, 26 Μαρ 2019 στις 11:47 μ.μ., ο/η Francis Chuang < > francischu...@apache.org> έγραψε: > > > Thanks for getting this release out, Kevin! > > > > While adding our new committers to the site, I noticed that the site > > branch is 7 commits ahead and 10 commits behind master. I was under the > > impression that the site and master branches should be even after a > > release, but I might be wrong. > > > > Francis > > > > On 26/03/2019 11:57 pm, Kevin Risden wrote: > > > Sent the release email after the website updated. I think I've > completed > > > all the 1.19 release manager steps. > > > > > > Kevin Risden > > > > > > > > > On Tue, Mar 26, 2019 at 8:33 AM Kevin Risden > wrote: > > > > > >> Committed the change to add JDK 12 to the 1.19.0 history. Should get > > >> published shortly. > > >> > > >> Kevin Risden > > >> > > >> > > >> On Tue, Mar 26, 2019 at 8:19 AM Kevin Risden > > wrote: > > >> > > >>> Julian - Yea that sounds good to add the JDK 12 piece. I am holding > off > > >>> adding it to the initial push to gitbox for calcite-site. I'll add it > > after > > >>> the first commit works and the site is published. > > >>> > > >>> Kevin Risden > > >>> > > >>> > > >>> On Mon, Mar 25, 2019 at 6:07 PM Julian Hyde > wrote: > > >>> > > >>>> I discovered one minor omission. We do not claim to have validated > > >>>> Calcite on JDK 12. But I did - so I think we can legitimately modify > > the > > >>>> release notes when we deploy the site. > > >>>> > > >>>> JDK 12 was released on 19th March, so is now the official latest > > version > > >>>> of Java. > > &
Re: [DISCUSS] Move site repositories from svn to gitbox
gitpubsub was enabled and changes to gitbox calcite-site repo are live on the site. The SVN repo should be read only now as well so we can't push to the wrong one :) Kevin Risden On Tue, Mar 26, 2019 at 10:29 AM Michael Mior wrote: > Thanks for tracking this Kevin! > > -- > Michael Mior > mm...@apache.org > Le mar. 26 mars 2019 à 08:18, > Kevin Risden > a écrit : > > > > Actually just followed up with infra. The gitpubsub hook should be > enabled > > in the next ~hour or less when puppet runs. I will hold off on the SVN > > change and make sure the gitbox calcite-site repo is working. > > > > Kevin Risden > > > > > > On Tue, Mar 26, 2019 at 8:11 AM Kevin Risden wrote: > > > > > Tried to push to the new gitbox site last night for the 1.19.0 release > and > > > ran into some issues. The gitpubsub hook was not setup so any changes > to > > > calcite-site on gitbox are not reflected on the site. I pinged INFRA > to get > > > this resolved. > > > > > > I am going to push the changes to SVN as well to get the site updated. > > > > > > Kevin Risden > > > > > > > > > On Sun, Feb 17, 2019 at 5:19 PM Francis Chuang < > francischu...@apache.org> > > > wrote: > > > > > >> @Michael, the svn repo will still be kept, but just unused. See > kafka's > > >> old site: https://svn.apache.org/repos/asf/kafka/site/ > > >> > > >> I have now pushed a the current working copy of our site to > > >> https://github.com/apache/calcite-site using svn export. > > >> > > >> I have also updated my ticket with infra to ask them to switch the > > >> site's publishing mechanism from svnpubsub to gitpubsub. > > >> > > >> I'll now proceed with updating the publishing instructions for our > site > > >> to git. > > >> > > >> On 16/02/2019 5:37 am, Julian Hyde wrote: > > >> > Agreed, the history of the web site is not very important. > > >> > > > >> > Julian > > >> > > > >> >> On Feb 15, 2019, at 5:58 AM, Michael Mior > wrote: > > >> >> > > >> >> I think we may want to keep the old SVN repository around if this > is > > >> >> the case, but I personally don't have a problem with losing > history in > > >> >> the new git repo. On a related note, it would be good to find a > > >> >> process for the new repo that can work with a shallow clone so we > > >> >> don't have to have the entire history of the site to push a change. > > >> >> > > >> >> -- > > >> >> Michael Mior > > >> >> mm...@apache.org > > >> >> > > >> >> Le ven. 15 févr. 2019 à 05:29, Francis Chuang > > >> >> a écrit : > > >> >>> > > >> >>> Hey everyone, > > >> >>> > > >> >>> I have now created the calcite-site repo in Gitbox. It is now > > >> available > > >> >>> via Github and the Gitbox endpoint, but currently empty. > > >> >>> > > >> >>> I am currently trying to migrate the svn repo, but it is taking a > very > > >> >>> long time and eventually timed out for me. A member of the ASF > infra > > >> >>> team has also confirmed that it can take hours or days to complete > > >> [1]. > > >> >>> > > >> >>> I feel that it would probably be easier if we just copy the > existing > > >> >>> files from the svn repo and make that the first commit in the git > > >> repo. > > >> >>> This is what Kafka did for their migration [2]. > > >> >>> > > >> >>> How important are the commits for site pushes? In my opinion it's > > >> >>> probably acceptable if we lose them and start anew with the git > repo > > >> as > > >> >>> they do not document changes to our code base. > > >> >>> > > >> >>> Happy to hear your thoughts! > > >> >>> > > >> >>> Francis > > >> >>> > > >> >>> [1] https://issues.apache.org/jira/browse/INFRA-17846 > > >> >>> [2] > > >> >>> > > >> > https://github.com/apache/kafka-site/c
Re: [DISCUSS] Towards Calcite 1.19.0
Sent the release email after the website updated. I think I've completed all the 1.19 release manager steps. Kevin Risden On Tue, Mar 26, 2019 at 8:33 AM Kevin Risden wrote: > Committed the change to add JDK 12 to the 1.19.0 history. Should get > published shortly. > > Kevin Risden > > > On Tue, Mar 26, 2019 at 8:19 AM Kevin Risden wrote: > >> Julian - Yea that sounds good to add the JDK 12 piece. I am holding off >> adding it to the initial push to gitbox for calcite-site. I'll add it after >> the first commit works and the site is published. >> >> Kevin Risden >> >> >> On Mon, Mar 25, 2019 at 6:07 PM Julian Hyde wrote: >> >>> I discovered one minor omission. We do not claim to have validated >>> Calcite on JDK 12. But I did - so I think we can legitimately modify the >>> release notes when we deploy the site. >>> >>> JDK 12 was released on 19th March, so is now the official latest version >>> of Java. >>> >>> I have logged https://issues.apache.org/jira/browse/CALCITE-2952 < >>> https://issues.apache.org/jira/browse/CALCITE-2952> for this task. >>> >>> Julian >>> >>> >>> > On Mar 25, 2019, at 7:56 AM, >>> Kevin Risden >>> wrote: >>> > >>> > Currently waiting the ~24 hour period for the release archives to >>> mirror. >>> > About ~9 more hours until that will be complete. I will regenerate the >>> site >>> > and push the site news item and send the announce email at that time. >>> > >>> > Kevin Risden >>> > >>> > >>> > On Wed, Mar 20, 2019 at 12:20 PM Kevin Risden >>> wrote: >>> > >>> >> RC0 and RC1 had a few issues identified. Those issues have been >>> resolved >>> >> and RC2 is being created and should be out later today. >>> >> >>> >> Kevin Risden >>> >> >>> >> >>> >> On Mon, Mar 11, 2019 at 10:24 PM Yuzhao Chen >>> wrote: >>> >> >>> >>> Nice job, Kevin >>> >>> >>> >>> Best, >>> >>> Yuzhao Chen >>> >>> 在 2019年3月11日 +0800 PM9:05， >>> >>> Kevin Risden >>> >>> ，写道： >>> >>>> As of this morning, all JIRAs tagged for 1.19.0 have been resolved >>> or >>> >>> moved >>> >>>> out to 1.20.0. >>> >>>> >>> >>>> I will be starting the release steps this morning. Please hold off >>> on >>> >>>> commits to master while the 1.19.0 release is happening. >>> >>>> >>> >>>> Kevin Risden >>> >>>> >>> >>>> >>> >>>> On Wed, Mar 6, 2019 at 9:02 AM Kevin Risden >>> wrote: >>> >>>> >>> >>>>> It looks like we haven't made any progress (JIRAs have been >>> >>> opened/closed) >>> >>>>> towards closing down JIRAs tagged for 1.19.0. There are still 14 >>> (14 >>> >>> on >>> >>>>> 2/27) open JIRAs tagged for 1.19.0. >>> >>>>> >>> >>>>> I will start moving those JIRAs out today to 1.20.0 so I can start >>> to >>> >>>>> close those this release. We are getting to mid March at this point >>> >>> since >>> >>>>> we keep postponing this release. >>> >>>>> >>> >>>>> Kevin Risden >>> >>>>> >>> >>>>> >>> >>>>> On Thu, Feb 28, 2019 at 5:55 AM YuZhao Chan >>> >>> wrote: >>> >>>>> >>> >>>>>> I would help to review some PRs this weekend，especially [1]. Hope >>> >>> to help >>> >>>>>> and release some of the burden. >>> >>>>>> [1] >>> >>>>>> >>> >>> >>> https://issues.apache.org/jira/browse/CALCITE-2018?jql=project%20%3D%20CALCITE%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(EMPTY%2C%20%22next%22)%20AND%20labels%20%3D%20pull-request-available%20ORDER%20BY%20priority%20DESC >>> >>>>>> >>> >>>>>> Best, >>> >>>>>> YuZhao Chan >>> >>>>>> 在 2019年2月26日 +0
[ANNOUNCE] Apache Calcite 1.19.0 released
The Apache Calcite team is pleased to announce the release of Apache Calcite 1.19.0. Calcite is a dynamic data management framework. Its cost-based optimizer converts queries, represented in relational algebra, into executable plans. Calcite supports many front-end languages and back-end data engines, and includes an SQL parser and the Avatica JDBC driver. This release comes three months after 1.18.0. It includes more than 80 resolved issues, comprising of a few new features as well as general improvements and bug-fixes. Among others, there have been significant improvements in JSON query support. For more details, see the release notes: https://calcite.apache.org/docs/history.html#v1-19-0 The release is available here: https://calcite.apache.org/downloads/ We welcome your help and feedback. For more information on how to report problems, and to get involved, visit the project website at https://calcite.apache.org Kevin Risden, on behalf of the Apache Calcite Team
Re: [DISCUSS] Towards Calcite 1.19.0
Committed the change to add JDK 12 to the 1.19.0 history. Should get published shortly. Kevin Risden On Tue, Mar 26, 2019 at 8:19 AM Kevin Risden wrote: > Julian - Yea that sounds good to add the JDK 12 piece. I am holding off > adding it to the initial push to gitbox for calcite-site. I'll add it after > the first commit works and the site is published. > > Kevin Risden > > > On Mon, Mar 25, 2019 at 6:07 PM Julian Hyde wrote: > >> I discovered one minor omission. We do not claim to have validated >> Calcite on JDK 12. But I did - so I think we can legitimately modify the >> release notes when we deploy the site. >> >> JDK 12 was released on 19th March, so is now the official latest version >> of Java. >> >> I have logged https://issues.apache.org/jira/browse/CALCITE-2952 < >> https://issues.apache.org/jira/browse/CALCITE-2952> for this task. >> >> Julian >> >> >> > On Mar 25, 2019, at 7:56 AM, >> Kevin Risden >> wrote: >> > >> > Currently waiting the ~24 hour period for the release archives to >> mirror. >> > About ~9 more hours until that will be complete. I will regenerate the >> site >> > and push the site news item and send the announce email at that time. >> > >> > Kevin Risden >> > >> > >> > On Wed, Mar 20, 2019 at 12:20 PM Kevin Risden >> wrote: >> > >> >> RC0 and RC1 had a few issues identified. Those issues have been >> resolved >> >> and RC2 is being created and should be out later today. >> >> >> >> Kevin Risden >> >> >> >> >> >> On Mon, Mar 11, 2019 at 10:24 PM Yuzhao Chen >> wrote: >> >> >> >>> Nice job, Kevin >> >>> >> >>> Best, >> >>> Yuzhao Chen >> >>> 在 2019年3月11日 +0800 PM9:05， >> >>> Kevin Risden >> >>> ，写道： >> >>>> As of this morning, all JIRAs tagged for 1.19.0 have been resolved or >> >>> moved >> >>>> out to 1.20.0. >> >>>> >> >>>> I will be starting the release steps this morning. Please hold off on >> >>>> commits to master while the 1.19.0 release is happening. >> >>>> >> >>>> Kevin Risden >> >>>> >> >>>> >> >>>> On Wed, Mar 6, 2019 at 9:02 AM Kevin Risden >> wrote: >> >>>> >> >>>>> It looks like we haven't made any progress (JIRAs have been >> >>> opened/closed) >> >>>>> towards closing down JIRAs tagged for 1.19.0. There are still 14 (14 >> >>> on >> >>>>> 2/27) open JIRAs tagged for 1.19.0. >> >>>>> >> >>>>> I will start moving those JIRAs out today to 1.20.0 so I can start >> to >> >>>>> close those this release. We are getting to mid March at this point >> >>> since >> >>>>> we keep postponing this release. >> >>>>> >> >>>>> Kevin Risden >> >>>>> >> >>>>> >> >>>>> On Thu, Feb 28, 2019 at 5:55 AM YuZhao Chan >> >>> wrote: >> >>>>> >> >>>>>> I would help to review some PRs this weekend，especially [1]. Hope >> >>> to help >> >>>>>> and release some of the burden. >> >>>>>> [1] >> >>>>>> >> >>> >> https://issues.apache.org/jira/browse/CALCITE-2018?jql=project%20%3D%20CALCITE%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(EMPTY%2C%20%22next%22)%20AND%20labels%20%3D%20pull-request-available%20ORDER%20BY%20priority%20DESC >> >>>>>> >> >>>>>> Best, >> >>>>>> YuZhao Chan >> >>>>>> 在 2019年2月26日 +0800 AM8:14，Julian Hyde ，写道： >> >>>>>>> Hey everyone. >> >>>>>>> >> >>>>>>> There are 108 open pull requests. What are we going to do about >> >>> it? >> >>>>>>> >> >>>>>>> Last release I reviewed and committed dozens of pull requests, >> >>> and I >> >>>>>> burned out. >> >>>>>>> >> >>>>>>> Julian >> >>>>>>> >> >>>>>>> >> >>>>>>&
Re: [DISCUSS] Towards Calcite 1.19.0
Julian - Yea that sounds good to add the JDK 12 piece. I am holding off adding it to the initial push to gitbox for calcite-site. I'll add it after the first commit works and the site is published. Kevin Risden On Mon, Mar 25, 2019 at 6:07 PM Julian Hyde wrote: > I discovered one minor omission. We do not claim to have validated Calcite > on JDK 12. But I did - so I think we can legitimately modify the release > notes when we deploy the site. > > JDK 12 was released on 19th March, so is now the official latest version > of Java. > > I have logged https://issues.apache.org/jira/browse/CALCITE-2952 < > https://issues.apache.org/jira/browse/CALCITE-2952> for this task. > > Julian > > > > On Mar 25, 2019, at 7:56 AM, > Kevin Risden > wrote: > > > > Currently waiting the ~24 hour period for the release archives to mirror. > > About ~9 more hours until that will be complete. I will regenerate the > site > > and push the site news item and send the announce email at that time. > > > > Kevin Risden > > > > > > On Wed, Mar 20, 2019 at 12:20 PM Kevin Risden > wrote: > > > >> RC0 and RC1 had a few issues identified. Those issues have been resolved > >> and RC2 is being created and should be out later today. > >> > >> Kevin Risden > >> > >> > >> On Mon, Mar 11, 2019 at 10:24 PM Yuzhao Chen > wrote: > >> > >>> Nice job, Kevin > >>> > >>> Best, > >>> Yuzhao Chen > >>> 在 2019年3月11日 +0800 PM9:05， > >>> Kevin Risden > >>> ，写道： > >>>> As of this morning, all JIRAs tagged for 1.19.0 have been resolved or > >>> moved > >>>> out to 1.20.0. > >>>> > >>>> I will be starting the release steps this morning. Please hold off on > >>>> commits to master while the 1.19.0 release is happening. > >>>> > >>>> Kevin Risden > >>>> > >>>> > >>>> On Wed, Mar 6, 2019 at 9:02 AM Kevin Risden > wrote: > >>>> > >>>>> It looks like we haven't made any progress (JIRAs have been > >>> opened/closed) > >>>>> towards closing down JIRAs tagged for 1.19.0. There are still 14 (14 > >>> on > >>>>> 2/27) open JIRAs tagged for 1.19.0. > >>>>> > >>>>> I will start moving those JIRAs out today to 1.20.0 so I can start to > >>>>> close those this release. We are getting to mid March at this point > >>> since > >>>>> we keep postponing this release. > >>>>> > >>>>> Kevin Risden > >>>>> > >>>>> > >>>>> On Thu, Feb 28, 2019 at 5:55 AM YuZhao Chan > >>> wrote: > >>>>> > >>>>>> I would help to review some PRs this weekend，especially [1]. Hope > >>> to help > >>>>>> and release some of the burden. > >>>>>> [1] > >>>>>> > >>> > https://issues.apache.org/jira/browse/CALCITE-2018?jql=project%20%3D%20CALCITE%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(EMPTY%2C%20%22next%22)%20AND%20labels%20%3D%20pull-request-available%20ORDER%20BY%20priority%20DESC > >>>>>> > >>>>>> Best, > >>>>>> YuZhao Chan > >>>>>> 在 2019年2月26日 +0800 AM8:14，Julian Hyde ，写道： > >>>>>>> Hey everyone. > >>>>>>> > >>>>>>> There are 108 open pull requests. What are we going to do about > >>> it? > >>>>>>> > >>>>>>> Last release I reviewed and committed dozens of pull requests, > >>> and I > >>>>>> burned out. > >>>>>>> > >>>>>>> Julian > >>>>>>> > >>>>>>> > >>>>>>>> On Feb 22, 2019, at 1:20 PM, > >>>>>> Kevin Risden > >>>>>> wrote: > >>>>>>>> > >>>>>>>> Yea I don't mind pushing out the RC towards the end of next week > >>>>>> (beginning > >>>>>>>> of March). I'm not in a rush to build the RC. I just picked > >>> Monday to > >>>>>> try > >>>>>>>> to hit the target of February that was arbitrarily picked in the > >>>>>> sand. At
Re: [DISCUSS] Move site repositories from svn to gitbox
Actually just followed up with infra. The gitpubsub hook should be enabled in the next ~hour or less when puppet runs. I will hold off on the SVN change and make sure the gitbox calcite-site repo is working. Kevin Risden On Tue, Mar 26, 2019 at 8:11 AM Kevin Risden wrote: > Tried to push to the new gitbox site last night for the 1.19.0 release and > ran into some issues. The gitpubsub hook was not setup so any changes to > calcite-site on gitbox are not reflected on the site. I pinged INFRA to get > this resolved. > > I am going to push the changes to SVN as well to get the site updated. > > Kevin Risden > > > On Sun, Feb 17, 2019 at 5:19 PM Francis Chuang > wrote: > >> @Michael, the svn repo will still be kept, but just unused. See kafka's >> old site: https://svn.apache.org/repos/asf/kafka/site/ >> >> I have now pushed a the current working copy of our site to >> https://github.com/apache/calcite-site using svn export. >> >> I have also updated my ticket with infra to ask them to switch the >> site's publishing mechanism from svnpubsub to gitpubsub. >> >> I'll now proceed with updating the publishing instructions for our site >> to git. >> >> On 16/02/2019 5:37 am, Julian Hyde wrote: >> > Agreed, the history of the web site is not very important. >> > >> > Julian >> > >> >> On Feb 15, 2019, at 5:58 AM, Michael Mior wrote: >> >> >> >> I think we may want to keep the old SVN repository around if this is >> >> the case, but I personally don't have a problem with losing history in >> >> the new git repo. On a related note, it would be good to find a >> >> process for the new repo that can work with a shallow clone so we >> >> don't have to have the entire history of the site to push a change. >> >> >> >> -- >> >> Michael Mior >> >> mm...@apache.org >> >> >> >> Le ven. 15 févr. 2019 à 05:29, Francis Chuang >> >> a écrit : >> >>> >> >>> Hey everyone, >> >>> >> >>> I have now created the calcite-site repo in Gitbox. It is now >> available >> >>> via Github and the Gitbox endpoint, but currently empty. >> >>> >> >>> I am currently trying to migrate the svn repo, but it is taking a very >> >>> long time and eventually timed out for me. A member of the ASF infra >> >>> team has also confirmed that it can take hours or days to complete >> [1]. >> >>> >> >>> I feel that it would probably be easier if we just copy the existing >> >>> files from the svn repo and make that the first commit in the git >> repo. >> >>> This is what Kafka did for their migration [2]. >> >>> >> >>> How important are the commits for site pushes? In my opinion it's >> >>> probably acceptable if we lose them and start anew with the git repo >> as >> >>> they do not document changes to our code base. >> >>> >> >>> Happy to hear your thoughts! >> >>> >> >>> Francis >> >>> >> >>> [1] https://issues.apache.org/jira/browse/INFRA-17846 >> >>> [2] >> >>> >> https://github.com/apache/kafka-site/commit/ba6c994ca09629b047ab9175f882877ba03b92da >> >>> >> >>>> On 11/02/2019 9:00 pm, Francis Chuang wrote: >> >>>> Hey all, >> >>>> >> >>>> ASF project sites have the ability to use git instead of subversion >> as >> >>>> their repository for web site content [1]. It has been available >> since >> >>>> 2015 and appears to be quite stable. Quite a few other projects have >> >>>> also moved their websites to git and subsequently, Gitbox (for using >> >>>> Github as their source of truth. As an example, see the Arrow >> project [2]. >> >>>> >> >>>> I myself would love to see this as I find gits interface and ux to be >> >>>> much easier to use compared to svn. It also reduces the need to >> context >> >>>> switch between Git and svn when editing and pushing the site. >> >>>> >> >>>> My overall goal is to find a way to automate the publishing and >> build of >> >>>> our websites either via Jenkins builds (there are some projects are >> >>>> doing this already when I searched infra) or the new Github actions >> [3]. >> >>>> Having the site hosted in Git would make this process much easier to >> >>>> automate. I will need to get in touch with infra to clarify a few >> things >> >>>> and to see if this is feasible, but I think this is a worthwhile >> endeavor. >> >>>> >> >>>> How do you guys feel about moving our site's repository from svn to >> GitBox? >> >>>> >> >>>> Francis >> >>>> >> >>>> >> >>>> [1] >> https://blogs.apache.org/infra/entry/git_based_websites_available >> >>>> [2] https://issues.apache.org/jira/browse/INFRA-17655 >> >>>> [3] https://github.com/features/actions >> >>> >> >>
Re: [DISCUSS] Move site repositories from svn to gitbox
Tried to push to the new gitbox site last night for the 1.19.0 release and ran into some issues. The gitpubsub hook was not setup so any changes to calcite-site on gitbox are not reflected on the site. I pinged INFRA to get this resolved. I am going to push the changes to SVN as well to get the site updated. Kevin Risden On Sun, Feb 17, 2019 at 5:19 PM Francis Chuang wrote: > @Michael, the svn repo will still be kept, but just unused. See kafka's > old site: https://svn.apache.org/repos/asf/kafka/site/ > > I have now pushed a the current working copy of our site to > https://github.com/apache/calcite-site using svn export. > > I have also updated my ticket with infra to ask them to switch the > site's publishing mechanism from svnpubsub to gitpubsub. > > I'll now proceed with updating the publishing instructions for our site > to git. > > On 16/02/2019 5:37 am, Julian Hyde wrote: > > Agreed, the history of the web site is not very important. > > > > Julian > > > >> On Feb 15, 2019, at 5:58 AM, Michael Mior wrote: > >> > >> I think we may want to keep the old SVN repository around if this is > >> the case, but I personally don't have a problem with losing history in > >> the new git repo. On a related note, it would be good to find a > >> process for the new repo that can work with a shallow clone so we > >> don't have to have the entire history of the site to push a change. > >> > >> -- > >> Michael Mior > >> mm...@apache.org > >> > >> Le ven. 15 févr. 2019 à 05:29, Francis Chuang > >> a écrit : > >>> > >>> Hey everyone, > >>> > >>> I have now created the calcite-site repo in Gitbox. It is now available > >>> via Github and the Gitbox endpoint, but currently empty. > >>> > >>> I am currently trying to migrate the svn repo, but it is taking a very > >>> long time and eventually timed out for me. A member of the ASF infra > >>> team has also confirmed that it can take hours or days to complete [1]. > >>> > >>> I feel that it would probably be easier if we just copy the existing > >>> files from the svn repo and make that the first commit in the git repo. > >>> This is what Kafka did for their migration [2]. > >>> > >>> How important are the commits for site pushes? In my opinion it's > >>> probably acceptable if we lose them and start anew with the git repo as > >>> they do not document changes to our code base. > >>> > >>> Happy to hear your thoughts! > >>> > >>> Francis > >>> > >>> [1] https://issues.apache.org/jira/browse/INFRA-17846 > >>> [2] > >>> > https://github.com/apache/kafka-site/commit/ba6c994ca09629b047ab9175f882877ba03b92da > >>> > >>>> On 11/02/2019 9:00 pm, Francis Chuang wrote: > >>>> Hey all, > >>>> > >>>> ASF project sites have the ability to use git instead of subversion as > >>>> their repository for web site content [1]. It has been available since > >>>> 2015 and appears to be quite stable. Quite a few other projects have > >>>> also moved their websites to git and subsequently, Gitbox (for using > >>>> Github as their source of truth. As an example, see the Arrow project > [2]. > >>>> > >>>> I myself would love to see this as I find gits interface and ux to be > >>>> much easier to use compared to svn. It also reduces the need to > context > >>>> switch between Git and svn when editing and pushing the site. > >>>> > >>>> My overall goal is to find a way to automate the publishing and build > of > >>>> our websites either via Jenkins builds (there are some projects are > >>>> doing this already when I searched infra) or the new Github actions > [3]. > >>>> Having the site hosted in Git would make this process much easier to > >>>> automate. I will need to get in touch with infra to clarify a few > things > >>>> and to see if this is feasible, but I think this is a worthwhile > endeavor. > >>>> > >>>> How do you guys feel about moving our site's repository from svn to > GitBox? > >>>> > >>>> Francis > >>>> > >>>> > >>>> [1] https://blogs.apache.org/infra/entry/git_based_websites_available > >>>> [2] https://issues.apache.org/jira/browse/INFRA-17655 > >>>> [3] https://github.com/features/actions > >>> > >
Re: [ANNOUNCE] New committers: Hongze Zhang
Congrats and welcome! Kevin Risden On Mon, Mar 25, 2019 at 8:51 PM Hongze Zhang wrote: > Thank you very much for your introduction (And no apology necessary :) ), > Francis ! And thank you all for the kind words. > > I am currently working at Tencent. During the last few months, I have been > focusing on providing near-standard SQL support for an existing streaming > compute engine. We introduce Calcite to the engine and it now works pretty > well. > > It is a great honor for me to become a committer of Apache Calcite. I also > look forward to contribute more in future. > > Thanks, > Hongze > > > On Mar 26, 2019, at 07:46, Stamatis Zampetakis > wrote: > > > > Congrats Hongze and welcome on board. > > > > Calcite support for JSON is getting better every day and there are many > > traits of you behind all that. > > Thanks a lot for your work on Calcite and looking forward working with > you. > > > > Best, > > Stamatis > > > > Στις Δευ, 25 Μαρ 2019 στις 10:28 μ.μ., ο/η Francis Chuang < > > francischu...@apache.org> έγραψε: > > > >> (Note: This was supposed to be sent last month, but I've somehow > >> forgotten. Please accept my apologies.) > >> > >> Apache Calcite's Project Management Committee (PMC) has invited Hongze > >> Zhang to become a committer, and we are pleased to announce that he has > >> accepted. > >> > >> Hongze has been a consistent contributor to Calcite, being responsible > >> for fixing various bugs and some pretty big patches. In addition, he has > >> been reviewing PRs and participating in discussions on our mailing > lists. > >> > >> Hongze, welcome, thank you for your contributions, and we look forward > >> your further interactions with the community! If you wish, please feel > >> free to tell us more about yourself and what you are working on. > >> > >> Francis (on behalf of the Apache Calcite PMC) > >> > >
Re: [ANNOUNCE] New committers: Haisheng Yuan
Congrats and welcome! Kevin Risden On Mon, Mar 25, 2019 at 7:46 PM Stamatis Zampetakis wrote: > Congrats Haiseng! Its great to have you with us in this new role. > > I am happy to learn that Alibaba MaxCompute query engine is using Calcite, > and very much like the idea of improving subquery handling. > > Welcome and thanks for all your work so far! > > Best, > Stamatis > > > > Στις Τρί, 26 Μαρ 2019 στις 12:35 π.μ., ο/η Haisheng Yuan < > h.y...@alibaba-inc.com> έγραψε: > > > Thank you for the introduction. > > > > I am currently working on Alibaba MaxCompute query engine, which uses > > Calcite for cost-based query optimization. I will also help flink/calcite > > integration, improve subquery unnesting, etc. > > > > It is my great honour to become a Calcite committer. Look forward to > > working with you all to make more contributions to Calcite project. > > > > Thanks ~ > > Haisheng Yuan > > -- > > 发件人：Francis Chuang > > 日 期：2019年03月26日 05:24:21 > > 收件人： > > 主 题：[ANNOUNCE] New committers: Haisheng Yuan > > > > Apache Calcite's Project Management Committee (PMC) has invited Haisheng > > Yuan to become a committer, and we are pleased to announce that he has > > accepted. > > > > Over the past few months, Haisheng has proposed numerous pull requests, > > reviewed PRs, participated in the mailing lists as well as filed > > numerous bugs on Jira. > > > > Haisheng, welcome, thank you for your contributions, and we look forward > > your further interactions with the community! If you wish, please feel > > free to tell us more about yourself and what you are working on. > > > > Francis (on behalf of the Apache Calcite PMC) > > >
Re: Calcite-Master - Build # 1078 - Still Failing
I don't think there are any downsides to changing to "mvn clean verify ..." other than the builds might take a bit longer. Kevin Risden On Mon, Mar 25, 2019 at 1:36 PM Hongze Zhang wrote: > Hi all, > > This is caused by a known problem which is analyzed in mail thread[1], and > it seems that the problem keeps failing our Jenkins build for a period of > time. I had tried cleaning Calcite's workspaces on several slave nodes but > it could not prevent the same error happening on other unexpected nodes. > > As a possible solution, do you think it's feasible to change our Jenkins > build command from "mvn verify ..." to "mvn clean verify ..."? > > Best, > Hongze > > > [1] > https://lists.apache.org/thread.html/%3C455426799.3105.1552292851062.JavaMail.jenkins@jenkins02%3E > > > > On Mar 25, 2019, at 23:29, Apache Jenkins Server < > jenk...@builds.apache.org> wrote: > > > > The Apache Jenkins build system has built Calcite-Master (build #1078) > > > > Status: Still Failing > > > > Check console output at > https://builds.apache.org/job/Calcite-Master/1078/ to view the results. > >
Master branch open to commits
I have completed all master branch related tasks for the 1.19.9 release. The master branch is now open to commits again. I am currently waiting the ~24 hour period for the release archives to mirror 1.19.0. About ~9 more hours until that will be complete. I will regenerate the site and push the site news item and send the announce email at that time. Kevin Risden
Re: [DISCUSS] Towards Calcite 1.19.0
Currently waiting the ~24 hour period for the release archives to mirror. About ~9 more hours until that will be complete. I will regenerate the site and push the site news item and send the announce email at that time. Kevin Risden On Wed, Mar 20, 2019 at 12:20 PM Kevin Risden wrote: > RC0 and RC1 had a few issues identified. Those issues have been resolved > and RC2 is being created and should be out later today. > > Kevin Risden > > > On Mon, Mar 11, 2019 at 10:24 PM Yuzhao Chen wrote: > >> Nice job, Kevin >> >> Best, >> Yuzhao Chen >> 在 2019年3月11日 +0800 PM9:05， >> Kevin Risden >> ，写道： >> > As of this morning, all JIRAs tagged for 1.19.0 have been resolved or >> moved >> > out to 1.20.0. >> > >> > I will be starting the release steps this morning. Please hold off on >> > commits to master while the 1.19.0 release is happening. >> > >> > Kevin Risden >> > >> > >> > On Wed, Mar 6, 2019 at 9:02 AM Kevin Risden wrote: >> > >> > > It looks like we haven't made any progress (JIRAs have been >> opened/closed) >> > > towards closing down JIRAs tagged for 1.19.0. There are still 14 (14 >> on >> > > 2/27) open JIRAs tagged for 1.19.0. >> > > >> > > I will start moving those JIRAs out today to 1.20.0 so I can start to >> > > close those this release. We are getting to mid March at this point >> since >> > > we keep postponing this release. >> > > >> > > Kevin Risden >> > > >> > > >> > > On Thu, Feb 28, 2019 at 5:55 AM YuZhao Chan >> wrote: >> > > >> > > > I would help to review some PRs this weekend，especially [1]. Hope >> to help >> > > > and release some of the burden. >> > > > [1] >> > > > >> https://issues.apache.org/jira/browse/CALCITE-2018?jql=project%20%3D%20CALCITE%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(EMPTY%2C%20%22next%22)%20AND%20labels%20%3D%20pull-request-available%20ORDER%20BY%20priority%20DESC >> > > > >> > > > Best, >> > > > YuZhao Chan >> > > > 在 2019年2月26日 +0800 AM8:14，Julian Hyde ，写道： >> > > > > Hey everyone. >> > > > > >> > > > > There are 108 open pull requests. What are we going to do about >> it? >> > > > > >> > > > > Last release I reviewed and committed dozens of pull requests, >> and I >> > > > burned out. >> > > > > >> > > > > Julian >> > > > > >> > > > > >> > > > > > On Feb 22, 2019, at 1:20 PM, >> > > > Kevin Risden >> > > > wrote: >> > > > > > >> > > > > > Yea I don't mind pushing out the RC towards the end of next week >> > > > (beginning >> > > > > > of March). I'm not in a rush to build the RC. I just picked >> Monday to >> > > > try >> > > > > > to hit the target of February that was arbitrarily picked in the >> > > > sand. At >> > > > > > this point, the release will most likely happen in early March. >> > > > > > >> > > > > > Kevin Risden >> > > > > > >> > > > > > >> > > > > > On Fri, Feb 22, 2019 at 4:15 PM Julian Hyde >> wrote: >> > > > > > >> > > > > > > Can you do the RC towards the end of next week? >> > > > > > > >> > > > > > > I only just saw this message - 4 days after you sent it - >> because >> > > > I’ve >> > > > > > > been fighting down a backlog of 500 Apache messages. There >> are some >> > > > changes >> > > > > > > I would like to get into the release but I will need a few >> days. >> > > > > > > >> > > > > > > Julian >> > > > > > > >> > > > > > > >> > > > > > > > On Feb 18, 2019, at 9:56 AM, >> > > > > > > Kevin Risden >> > > > > > > wrote: >> > > > > > > > >> > > > > > > > It looks like there are some PRs to be reviewed and some >> changes >> > > > to get >> > > > > > > > merged in this week.
[RESULT] [VOTE] Release apache-calcite-1.19.0 (release candidate 2)
Thanks to everyone who has tested the release candidate and given their comments and votes. The tally is as follows. 4 binding +1s: Francis Chuang Julian Hyde Kevin Risden Jesus Camacho Rodriguez 3 non-binding +1s: Enrico Olivelli Andrei Sereda Stamatis Zampetakis No 0s or -1s. Therefore I am delighted to announce that the proposal to release Apache Calcite 1.19.0 has passed. Thanks everyone. We’ll now roll the release out to the mirrors. Kevin Risden
[VOTE] Release apache-calcite-1.19.0 (release candidate 2)
Hi all, I have created a build for Apache Calcite 1.19.0, release candidate 2. Thanks to everyone who has contributed to this release. Since RC 1, we have fixed the following issues: * [CALCITE-2929] Simplification of IS NULL checks are incorrectly assuming that CAST-s are possible * [CALCITE-2931] Mongo Adapter- Compare Bson (not string) query representation in tests * [CALCITE-2932] Update stale Druid integration test cases You can read the release notes here: https://github.com/apache/calcite/blob/branch-1.19/site/_docs/history.md The commit to be voted upon: https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=4143176acdb2860b3a80eb18e4cb1557f5969d13 Its hash is 4143176acdb2860b3a80eb18e4cb1557f5969d13. The artifacts to be voted on are located here: https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.19.0-rc2/ The hashes of the artifacts are as follows: src.tar.gz.sha256 833fa3e9c97d8e89443f3b7a62fc6cce5f0e734836d82db1443425be6ac5dc65 A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachecalcite-1057/ Release artifacts are signed with the following key: https://people.apache.org/keys/committer/krisden.asc Please vote on releasing this package as Apache Calcite 1.19.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.19.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) Kevin Risden
Re: [DISCUSS] Towards Calcite 1.19.0
RC0 and RC1 had a few issues identified. Those issues have been resolved and RC2 is being created and should be out later today. Kevin Risden On Mon, Mar 11, 2019 at 10:24 PM Yuzhao Chen wrote: > Nice job, Kevin > > Best, > Yuzhao Chen > 在 2019年3月11日 +0800 PM9:05， > Kevin Risden > ，写道： > > As of this morning, all JIRAs tagged for 1.19.0 have been resolved or > moved > > out to 1.20.0. > > > > I will be starting the release steps this morning. Please hold off on > > commits to master while the 1.19.0 release is happening. > > > > Kevin Risden > > > > > > On Wed, Mar 6, 2019 at 9:02 AM Kevin Risden wrote: > > > > > It looks like we haven't made any progress (JIRAs have been > opened/closed) > > > towards closing down JIRAs tagged for 1.19.0. There are still 14 (14 on > > > 2/27) open JIRAs tagged for 1.19.0. > > > > > > I will start moving those JIRAs out today to 1.20.0 so I can start to > > > close those this release. We are getting to mid March at this point > since > > > we keep postponing this release. > > > > > > Kevin Risden > > > > > > > > > On Thu, Feb 28, 2019 at 5:55 AM YuZhao Chan > wrote: > > > > > > > I would help to review some PRs this weekend，especially [1]. Hope to > help > > > > and release some of the burden. > > > > [1] > > > > > https://issues.apache.org/jira/browse/CALCITE-2018?jql=project%20%3D%20CALCITE%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(EMPTY%2C%20%22next%22)%20AND%20labels%20%3D%20pull-request-available%20ORDER%20BY%20priority%20DESC > > > > > > > > Best, > > > > YuZhao Chan > > > > 在 2019年2月26日 +0800 AM8:14，Julian Hyde ，写道： > > > > > Hey everyone. > > > > > > > > > > There are 108 open pull requests. What are we going to do about it? > > > > > > > > > > Last release I reviewed and committed dozens of pull requests, and > I > > > > burned out. > > > > > > > > > > Julian > > > > > > > > > > > > > > > > On Feb 22, 2019, at 1:20 PM, > > > > Kevin Risden > > > > wrote: > > > > > > > > > > > > Yea I don't mind pushing out the RC towards the end of next week > > > > (beginning > > > > > > of March). I'm not in a rush to build the RC. I just picked > Monday to > > > > try > > > > > > to hit the target of February that was arbitrarily picked in the > > > > sand. At > > > > > > this point, the release will most likely happen in early March. > > > > > > > > > > > > Kevin Risden > > > > > > > > > > > > > > > > > > On Fri, Feb 22, 2019 at 4:15 PM Julian Hyde > wrote: > > > > > > > > > > > > > Can you do the RC towards the end of next week? > > > > > > > > > > > > > > I only just saw this message - 4 days after you sent it - > because > > > > I’ve > > > > > > > been fighting down a backlog of 500 Apache messages. There are > some > > > > changes > > > > > > > I would like to get into the release but I will need a few > days. > > > > > > > > > > > > > > Julian > > > > > > > > > > > > > > > > > > > > > > On Feb 18, 2019, at 9:56 AM, > > > > > > > Kevin Risden > > > > > > > wrote: > > > > > > > > > > > > > > > > It looks like there are some PRs to be reviewed and some > changes > > > > to get > > > > > > > > merged in this week. > > > > > > > > > > > > > > > > How does creating the first RC on Monday Feb 25th sound? Does > > > > that give > > > > > > > > enough time this week to get changes into Calcite 1.19.0? > > > > > > > > > > > > > > > > Kevin Risden > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 13, 2019 at 11:08 AM Zoltan Haindrich < > k...@rxd.hu> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/13/19 4:24
Re: How to start up the vm environment after i do Vagrant halt ?
There may be a manual way to start Druid but I wasn't sure. I poked around for a bit. I ran into the same issues while testing the test vm. halt / up doesn't restart all the services. I just created https://github.com/vlsi/calcite-test-dataset/issues/29 Kevin Risden On Wed, Mar 20, 2019 at 6:18 AM Yuzhao Chen wrote: > Hi, guys. > > After I did the cmd: vagrant halt and vagrant up, i can not connect to the > druid broker again, so what it the right way to halt and start up ? > > > Best, > Danny Chan >
[CANCEL][VOTE] Release apache-calcite-1.19.0 (release candidate 0)
RC 0 was cancelled due to CALCITE-2925 <https://issues.apache.org/jira/browse/CALCITE-2925> Kevin Risden On Mon, Mar 18, 2019 at 7:04 PM Julian Hyde wrote: > Kevin, > > I think you should send a [CANCEL] message to formally cancel the vote for > RC 0. > > Julian > > > > On Mar 18, 2019, at 10:39 AM, > Kevin Risden > wrote: > > > > Vote on RC1. The mvnw jar file was removed. Including the mvnw jar was a > > change from previous releases. Other binary files have been in previous > > releases since they are needed to build/test Calcite. > > > > Kevin Risden > > > > > > On Mon, Mar 18, 2019 at 11:58 AM Andrei Sereda wrote: > > > >> Hello, > >> > >> Can one vote on RC 1 (separate thread) or should we wait on decision > >> wherever having jar files in calcite source distribution is acceptable ? > >> > >> On Fri, Mar 15, 2019 at 4:08 PM Vladimir Sitnikov < > >> sitnikov.vladi...@gmail.com> wrote: > >> > >>> Julian> Lastly, this .jar file is non-essential. The release builds > >>> just fine without it. > >>> > >>> The use of consistent build tool versions would reduce risks. > >>> For instance: Maven 3.6.1-SNAPSHOT might happen to build Calcite "just > >>> fine" yet it could silently corrupt something. > >>> Then ./mvnw does not verify download integrity, so it makes > >>> build/release less secure. > >>> > >>> Why take those risks? > >>> How can I validate calcite.jar artifacts that are uploaded to Maven > >>> repository? Which tool could I use to validate that jars match the > >>> expected ones? > >>> Can I vote for source artifacts only and explicitly veto binary jars > >>> on a basis of "I can't validate wha's inside"? > >>> > >>> Even though Maven does not support wrapper natively, the case for > >>> wrapper would be even more important when we use Gradle. > >>> > >>> I see a couple of options: > >>> A) Include maven-wrapper.jar, and put its expected SHA256 side by > >>> side. We don't update the file often, so "IP and/or tampering" could > >>> be checked by verifying SHA for the jar file. > >>> > >>> B) We could include maven-wrapper in a source form and build it during > >>> the very first mvnw call. All the *.java files for maven-wrapper sum > >>> up to 70KiB which is just tiny. > >>> A single JdbcTest.jar is 350KiB. > >>> > >>> Any thoughts? > >>> ^^ The question above is quite real and I guess the answer would be > >>> pretty much reused for Gradle-based build. > >>> > >>> Julian> Since we have created them, and they are available nowhere > else, > >>> they > >>> Julian> belong in the source release. > >>> > >>> I don't think we created fontawesome-webfont.ttf, did we? > >>> Technically speaking, calcite/site/fonts is 500+KiB which does look > >>> like binary files. > >>> > >>> Julian> Code is different. The textual source is editable, but the > object > >>> Julian> files (in this case the .class files in the .jar) are not. > >>> > >>> As you know, "TrueType systems include a virtual machine that > >>> executes programs inside the font", so *.ttf is an object file. > >>> There are CVEs for TTF processing. > >>> > >>> Even though it might sound like a stretch, I don't quite buy "having > >>> consistent build system is not important" kind of conclusions. > >>> > >>> Vladimir > >>> > >> > >
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 1)
Thanks to all those who tested RC 1. Triaged issues in RC 1: - CALCITE-2918 - JdbcTest / JdbcAdapterTest - Postgres - existing issue with operator precedence - thanks Stamatis Zampetakis and Zoltan Haindrich for helping track down root cause - no PR - tagged for 1.20.0 since it is an existing underlying issue with operator precedence - CALCITE-2929 - cast IS NULL discards errors - PR available - thanks Zoltan Haindrich - CALCITE-2931 - MongoAdapterIT - integration test only order of BSON document fields - PR available - thanks Andrei Sereda - CALCITE-2932 - DruidAdapterIT - multiple failures from changes not being applied to druid adapter - PR available - thanks Hongze Zhang and Stamatis Zampetakis - CALCITE-2934 - simplification of a filter =($0, false) to NOT($0) ($0 is boolean) - I think this should wait for 1.20.0 since as Stamatis said its a valid simplification just may not be ideal in all cases. Based on the above, CALCITE-2929 and CALCITE-2932 seem to require a new RC. I plan to create a new RC for 1.19.0 which will include CALCITE-2931, CALCITE-2932, and CALCITE-2929 when they are finished. They have PRs currently so should be possible to resolve soon. I have marked those JIRAs as blockers of CALCITE-2911 - Release Calcite 1.19.0. Kevin Risden On Tue, Mar 19, 2019 at 6:21 AM Zoltan Haindrich wrote: > On 3/19/19 8:33 AM, Zoltan Haindrich wrote: > > > * I've been using some jenkins jobs to run calcite tests - and in yesterday's > builds TpchTest started hanging (and timeouted after 10h) even in master > branch builds > > > I've run all tests locally on my machine - they passed; I right now doubt > that it would be a real issue...it could be some > platform/machine/configuration dependent issue. > > this issue was unrelated > sorry for the noise >
[jira] [Created] (CALCITE-2934) Simplification of a filter =($0, false) to NOT($0) ($0 is boolean)
Kevin Risden created CALCITE-2934: - Summary: Simplification of a filter =($0, false) to NOT($0) ($0 is boolean) Key: CALCITE-2934 URL: https://issues.apache.org/jira/browse/CALCITE-2934 Project: Calcite Issue Type: Bug Reporter: Stamatis Zampetakis Fix For: 1.20.0 The errors occur due to the simplification of a filter =($0, false) to NOT($0) ($0 is boolean). The transformation is valid so in principle the tests should not fail. However it makes me wonder if adding negation is really a simplification. If I want to push this expression into an index (e.g., B+Tree) I would have to rewrite it again to something equivalent to =($0, false) since many types of indexes do not support negative conditions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Druid/MongoDB Integration test failures was: [VOTE] Release apache-calcite-1.19.0 (release candidate 1)
Was able to get the VM build and reproduces the errors:
https://issues.apache.org/jira/browse/CALCITE-2932
Planning to add more commentary there.
Kevin Risden
On Mon, Mar 18, 2019 at 5:45 PM Andrei Sereda wrote:
> Sure. Let me know if you need help with Druid adapter.
>
> On Mon, Mar 18, 2019 at 5:36 PM
> Kevin Risden
> wrote:
>
> > Rebuilding the VM for just druid found that there is an issue with
> > zookeeper version - 3.4.10 doesn't exist on the release mirrors anymore
> for
> > when installing druid. Fixing to point to 3.4.13 and see if that will let
> > me build the test vm correctly.
> >
> > Kevin Risden
> >
> >
> > On Mon, Mar 18, 2019 at 5:32 PM Kevin Risden wrote:
> >
> > > Andrei - Thanks I just checked the results and see the same thing for
> > > MongoDB. I see you opened CALCITE-2931 as well with a PR. Since this is
> > > test only don't think this blocks the 1.19.0 release.
> > >
> > > As for Druid, looks like I'm still getting connection reset errors
> after
> > > rebuilding the test dataset vm. I'm going to try to rebuild the VM with
> > > just Druid to see if its a memory issue.
> > >
> > > Kevin Risden
> > >
> > >
> > > On Mon, Mar 18, 2019 at 4:54 PM Andrei Sereda
> wrote:
> > >
> > >> I just run Mongo tests using docker image.
> > >>
> > >> Failures seem to be related to key order in Bson document. Example:
> > >>
> > >> Expected
> > >> {$project: {POP: '$pop', STATE: '$state'}}
> > >>
> > >> Actual
> > >> {$project: {STATE: '$state', POP: '$pop'}}
> > >>
> > >> Those queries don't run as part of unit tests because they only work
> in
> > >> mongo (not fongo).
> > >>
> > >> I will address those inconsistencies
> > >> (MongoAdapterTest#testGroupByAvgSumCount and
> > >> MongoAdapterTest#testDistinctCountOrderBy)
> > >>
> > >> On Mon, Mar 18, 2019 at 2:05 PM
> > >> Kevin Risden
> > >> wrote:
> > >>
> > >> > For the calcite-test-dataset vm, the docs say you can halt/up the
> VM.
> > It
> > >> > turns out that Druid doesn't restart on up and MongoDB fails to
> start
> > >> due
> > >> > to /var/run/mongodb missing. /var/run is symlinked to /run and /run
> is
> > >> > mounted as tmpfs so the folders are cleared on a restart.
> > >> >
> > >> > I don't know if this is what is causing the failures you saw but it
> > was
> > >> > causing issues with the "timeout" issues I saw. I am rebuilding the
> VM
> > >> and
> > >> > checking the Druid / MongoDB integration tests individually.
> > >> >
> > >> > Kevin Risden
> > >> >
> > >> >
> > >> > On Mon, Mar 18, 2019 at 1:43 PM Kevin Risden
> > >> wrote:
> > >> >
> > >> > > Stamatis - Can you open JIRA cases for the Druid and MongoDB
> > >> integration
> > >> > > test failures with details?
> > >> > >
> > >> > > It would be good to track them down not sure if they would block
> the
> > >> > > release depending on the errors. I seem to have an issue with my
> > >> > > calcite-test-dataset vm currently since getting timeout errors for
> > >> Mongo
> > >> > > and Druid. I'll see if I can track them down but would be good to
> > see
> > >> > what
> > >> > > the failure details are.
> > >> > >
> > >> > > I did not see the MySQL test failure. I could have missed the
> > >> > > Druid/MongoDB integration test failures since the integration test
> > run
> > >> > > stopped at Postgres.
> > >> > >
> > >> > > Kevin Risden
> > >> > >
> > >> > >
> > >> > > On Mon, Mar 18, 2019 at 12:09 PM Stamatis Zampetakis <
> > >> zabe...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > >> System A: MacOS 10.13.6, jdk9, maven 3.5.2
> > >> > >> System B: Ubuntu 18.04LTS, jdk1.8.0_192, maven 3.5.3
> > >> > >>
> > >> > >> -run unit tests (mvn clean install) on staged sources and git
> repo
> > OK
> > >> > >> -ch
[jira] [Created] (CALCITE-2932) DruidAdapterIT test failures
Kevin Risden created CALCITE-2932:
-
Summary: DruidAdapterIT test failures
Key: CALCITE-2932
URL: https://issues.apache.org/jira/browse/CALCITE-2932
Project: Calcite
Issue Type: Test
Reporter: Kevin Risden
Output below from running:
{code:java}
./mvnw verify -Pit -DfailIfNoTests=false -Dtest=DoesNotExist
-Dit.test=DruidAdapterIT
{code}
{code:java}
[INFO] Running org.apache.calcite.test.DruidAdapterIT
[ERROR] Tests run: 234, Failures: 16, Errors: 6, Skipped: 0, Time elapsed:
96.879 s <<< FAILURE! - in org.apache.calcite.test.DruidAdapterIT
[ERROR] testComplexExpressionsIsNull(org.apache.calcite.test.DruidAdapterIT)
Time elapsed: 3.725 s <<< FAILURE!
java.lang.AssertionError:
Expected: a string containing "PLAN=EnumerableInterpreter\n
BindableAggregate(group=[{}], EXPR$0=[$SUM0($1)])\n
BindableFilter(condition=[IS NULL(+(null, CAST($0):INTEGER))])\n
DruidQuery(table=[[foodmart, foodmart]],
intervals=[[1900-01-09T00:00:00.000Z/2992-01-10T00:00:00.000Z]], groups=[{29}],
aggs=[[COUNT()]])"
but: was "PLAN=EnumerableInterpreter\n DruidQuery(table=[[foodmart, foodmart]],
intervals=[[1900-01-09T00:00:00.000Z/2992-01-10T00:00:00.000Z]],
projects=[[0]], groups=[{}], aggs=[[COUNT()]])\n\n"
at
org.apache.calcite.test.DruidAdapterIT.testComplexExpressionsIsNull(DruidAdapterIT.java:3475)
[ERROR] testQueryWithExtractsTimes(org.apache.calcite.test.DruidAdapterIT) Time
elapsed: 30.195 s <<< FAILURE!
java.lang.AssertionError:
Expected: a string containing "PLAN=EnumerableInterpreter\n
BindableProject(QUARTER=[$4], WEEK=[$0], DAYOFWEEK=[$1], DAYOFMONTH=[$2],
DAYOFYEAR=[$3], SUM_ADDED=[$5])\n BindableSort(fetch=[1])\n
DruidQuery(table=[[wiki, wikiticker]],
intervals=[[1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z]],
projects=[[EXTRACT(FLAG(WEEK), $0), EXTRACT(FLAG(DOW), $0), EXTRACT(FLAG(DAY),
$0), EXTRACT(FLAG(DOY), $0), EXTRACT(FLAG(QUARTER), $0), $1]], groups=[{0, 1,
2, 3, 4}], aggs=[[SUM($5)]], sort0=[5], dir0=[ASC])"
but: was "PLAN=EnumerableInterpreter\n BindableProject(QUARTER=[$4], WEEK=[$0],
DAYOFWEEK=[$1], DAYOFMONTH=[$2], DAYOFYEAR=[$3], SUM_ADDED=[$5])\n
DruidQuery(table=[[wiki, wikiticker]],
intervals=[[1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z]],
projects=[[EXTRACT(FLAG(WEEK), $0), EXTRACT(FLAG(DOW), $0), EXTRACT(FLAG(DAY),
$0), EXTRACT(FLAG(DOY), $0), EXTRACT(FLAG(QUARTER), $0), $1]], groups=[{0, 1,
2, 3, 4}], aggs=[[SUM($5)]], fetch=[1])\n\n"
at
org.apache.calcite.test.DruidAdapterIT.testQueryWithExtractsTimes(DruidAdapterIT.java:4344)
[ERROR] testPushCast(org.apache.calcite.test.DruidAdapterIT) Time elapsed:
4.556 s <<< FAILURE!
java.lang.AssertionError:
Expected: a string containing "PLAN=EnumerableInterpreter\n
BindableSort(sort0=[$0], dir0=[ASC], fetch=[5])\n
BindableFilter(condition=[=($0, null)])\n DruidQuery(table=[[foodmart,
foodmart]], intervals=[[1900-01-09T00:00:00.000Z/2992-01-10T00:00:00.000Z]],
groups=[{1}], aggs=[[]])"
but: was "PLAN=EnumerableInterpreter\n DruidQuery(table=[[foodmart, foodmart]],
intervals=[[1900-01-09T00:00:00.000Z/2992-01-10T00:00:00.000Z]],
filter=[false], groups=[{1}], aggs=[[]], sort0=[0], dir0=[ASC], fetch=[5])\n\n"
at org.apache.calcite.test.DruidAdapterIT.testPushCast(DruidAdapterIT.java:1944)
[ERROR] testPartiallyPostAggregation(org.apache.calcite.test.DruidAdapterIT)
Time elapsed: 23.506 s <<< FAILURE!
java.lang.AssertionError:
Expected: a string containing "DruidQuery(table=[[foodmart, foodmart]],
intervals=[[1900-01-09T00:00:00.000Z/2992-01-10T00:00:00.000Z]],
projects=[[$63, $89, $90, $91]], groups=[{0}], aggs=[[SUM($2), SUM($3),
SUM($1)]], post_projects=[[$0, /($1, $2), CASE(=($3, 0), 1.0,
CAST($3):DECIMAL(19, 0))]], sort0=[1], dir0=[DESC])"
but: was "PLAN=EnumerableInterpreter\n DruidQuery(table=[[foodmart, foodmart]],
intervals=[[1900-01-09T00:00:00.000Z/2992-01-10T00:00:00.000Z]],
projects=[[$63, $89, $90, $91]], groups=[{0}], aggs=[[SUM($2), SUM($3),
SUM($1)]], post_projects=[[$0, /($1, $2), CASE(=($3, 0), 1.0:DECIMAL(19, 0),
CAST($3):DECIMAL(19, 0))]], sort0=[1], dir0=[DESC])\n\n"
at
org.apache.calcite.test.DruidAdapterIT.testPartiallyPostAggregation(DruidAdapterIT.java:2203)
[ERROR]
testExpressionsFilterWithCastTimeToDateToChar(org.apache.calcite.test.DruidAdapterIT)
Time elapsed: 0.336 s <<< FAILURE!
java.lang.AssertionError:
Expected: a string containing "PLAN=EnumerableInterpreter\n
DruidQuery(table=[[foodmart, foodmart]],
intervals=[[1900-01-09T00:00:00.000Z/2992-01-10T00:00:00.000Z]],
filter=[=(CAST(CAST($0):DATE NOT NULL):VARCHAR CHARACTER SET \"ISO-8859-1\"
COLLATE \"ISO-8859-1$en_US$primary\" NOT NULL, '1997-01-01')], groups=[{}],
aggs=[[COUNT()]])"
but: was "PLAN=EnumerableInterpreter\n DruidQu
Re: Druid/MongoDB Integration test failures was: [VOTE] Release apache-calcite-1.19.0 (release candidate 1)
Rebuilding the VM for just druid found that there is an issue with
zookeeper version - 3.4.10 doesn't exist on the release mirrors anymore for
when installing druid. Fixing to point to 3.4.13 and see if that will let
me build the test vm correctly.
Kevin Risden
On Mon, Mar 18, 2019 at 5:32 PM Kevin Risden wrote:
> Andrei - Thanks I just checked the results and see the same thing for
> MongoDB. I see you opened CALCITE-2931 as well with a PR. Since this is
> test only don't think this blocks the 1.19.0 release.
>
> As for Druid, looks like I'm still getting connection reset errors after
> rebuilding the test dataset vm. I'm going to try to rebuild the VM with
> just Druid to see if its a memory issue.
>
> Kevin Risden
>
>
> On Mon, Mar 18, 2019 at 4:54 PM Andrei Sereda wrote:
>
>> I just run Mongo tests using docker image.
>>
>> Failures seem to be related to key order in Bson document. Example:
>>
>> Expected
>> {$project: {POP: '$pop', STATE: '$state'}}
>>
>> Actual
>> {$project: {STATE: '$state', POP: '$pop'}}
>>
>> Those queries don't run as part of unit tests because they only work in
>> mongo (not fongo).
>>
>> I will address those inconsistencies
>> (MongoAdapterTest#testGroupByAvgSumCount and
>> MongoAdapterTest#testDistinctCountOrderBy)
>>
>> On Mon, Mar 18, 2019 at 2:05 PM
>> Kevin Risden
>> wrote:
>>
>> > For the calcite-test-dataset vm, the docs say you can halt/up the VM. It
>> > turns out that Druid doesn't restart on up and MongoDB fails to start
>> due
>> > to /var/run/mongodb missing. /var/run is symlinked to /run and /run is
>> > mounted as tmpfs so the folders are cleared on a restart.
>> >
>> > I don't know if this is what is causing the failures you saw but it was
>> > causing issues with the "timeout" issues I saw. I am rebuilding the VM
>> and
>> > checking the Druid / MongoDB integration tests individually.
>> >
>> > Kevin Risden
>> >
>> >
>> > On Mon, Mar 18, 2019 at 1:43 PM Kevin Risden
>> wrote:
>> >
>> > > Stamatis - Can you open JIRA cases for the Druid and MongoDB
>> integration
>> > > test failures with details?
>> > >
>> > > It would be good to track them down not sure if they would block the
>> > > release depending on the errors. I seem to have an issue with my
>> > > calcite-test-dataset vm currently since getting timeout errors for
>> Mongo
>> > > and Druid. I'll see if I can track them down but would be good to see
>> > what
>> > > the failure details are.
>> > >
>> > > I did not see the MySQL test failure. I could have missed the
>> > > Druid/MongoDB integration test failures since the integration test run
>> > > stopped at Postgres.
>> > >
>> > > Kevin Risden
>> > >
>> > >
>> > > On Mon, Mar 18, 2019 at 12:09 PM Stamatis Zampetakis <
>> zabe...@gmail.com>
>> > > wrote:
>> > >
>> > >> System A: MacOS 10.13.6, jdk9, maven 3.5.2
>> > >> System B: Ubuntu 18.04LTS, jdk1.8.0_192, maven 3.5.3
>> > >>
>> > >> -run unit tests (mvn clean install) on staged sources and git repo OK
>> > >> -checked signatures and checksums OK
>> > >> -went quickly over release note OK
>> > >> -run integration tests (mvn -Dtest=foo -DfailIfNoTests=false -Pit
>> verify
>> > >> -fn) KO
>> > >> A brief summary of the errors is given below:
>> > >> [ERROR] Tests run: 290, Failures: 1, Errors: 0, Skipped: 21, Time
>> > elapsed:
>> > >> 23.703 s <<< FAILURE! - in org.apache.calcite.test.JdbcTest (MySQL)
>> > >> [ERROR] Tests run: 290, Failures: 0, Errors: 1, Skipped: 21, Time
>> > elapsed:
>> > >> 34.468 s <<< FAILURE! - in org.apache.calcite.test.JdbcTest
>> (Postgres)
>> > >> [ERROR] Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time
>> elapsed:
>> > >> 1.478 s <<< FAILURE! - in org.apache.calcite.test.JdbcAdapterTest
>> > >> (Postgres)
>> > >> [ERROR] Tests run: 234, Failures: 16, Errors: 6, Skipped: 0, Time
>> > elapsed:
>> > >> 52.406 s <<< FAILURE! - in org.apache.calcite.test.DruidAdapterIT
>> > (Druid)
>> > >> [ERROR] Tests run: 31, Failures: 2, Errors: 0, Skipped: 6, Time
>> elapsed:
>> > >> 3.236 s <<< FAILURE! - i
Re: Druid/MongoDB Integration test failures was: [VOTE] Release apache-calcite-1.19.0 (release candidate 1)
Andrei - Thanks I just checked the results and see the same thing for
MongoDB. I see you opened CALCITE-2931 as well with a PR. Since this is
test only don't think this blocks the 1.19.0 release.
As for Druid, looks like I'm still getting connection reset errors after
rebuilding the test dataset vm. I'm going to try to rebuild the VM with
just Druid to see if its a memory issue.
Kevin Risden
On Mon, Mar 18, 2019 at 4:54 PM Andrei Sereda wrote:
> I just run Mongo tests using docker image.
>
> Failures seem to be related to key order in Bson document. Example:
>
> Expected
> {$project: {POP: '$pop', STATE: '$state'}}
>
> Actual
> {$project: {STATE: '$state', POP: '$pop'}}
>
> Those queries don't run as part of unit tests because they only work in
> mongo (not fongo).
>
> I will address those inconsistencies
> (MongoAdapterTest#testGroupByAvgSumCount and
> MongoAdapterTest#testDistinctCountOrderBy)
>
> On Mon, Mar 18, 2019 at 2:05 PM
> Kevin Risden
> wrote:
>
> > For the calcite-test-dataset vm, the docs say you can halt/up the VM. It
> > turns out that Druid doesn't restart on up and MongoDB fails to start due
> > to /var/run/mongodb missing. /var/run is symlinked to /run and /run is
> > mounted as tmpfs so the folders are cleared on a restart.
> >
> > I don't know if this is what is causing the failures you saw but it was
> > causing issues with the "timeout" issues I saw. I am rebuilding the VM
> and
> > checking the Druid / MongoDB integration tests individually.
> >
> > Kevin Risden
> >
> >
> > On Mon, Mar 18, 2019 at 1:43 PM Kevin Risden wrote:
> >
> > > Stamatis - Can you open JIRA cases for the Druid and MongoDB
> integration
> > > test failures with details?
> > >
> > > It would be good to track them down not sure if they would block the
> > > release depending on the errors. I seem to have an issue with my
> > > calcite-test-dataset vm currently since getting timeout errors for
> Mongo
> > > and Druid. I'll see if I can track them down but would be good to see
> > what
> > > the failure details are.
> > >
> > > I did not see the MySQL test failure. I could have missed the
> > > Druid/MongoDB integration test failures since the integration test run
> > > stopped at Postgres.
> > >
> > > Kevin Risden
> > >
> > >
> > > On Mon, Mar 18, 2019 at 12:09 PM Stamatis Zampetakis <
> zabe...@gmail.com>
> > > wrote:
> > >
> > >> System A: MacOS 10.13.6, jdk9, maven 3.5.2
> > >> System B: Ubuntu 18.04LTS, jdk1.8.0_192, maven 3.5.3
> > >>
> > >> -run unit tests (mvn clean install) on staged sources and git repo OK
> > >> -checked signatures and checksums OK
> > >> -went quickly over release note OK
> > >> -run integration tests (mvn -Dtest=foo -DfailIfNoTests=false -Pit
> verify
> > >> -fn) KO
> > >> A brief summary of the errors is given below:
> > >> [ERROR] Tests run: 290, Failures: 1, Errors: 0, Skipped: 21, Time
> > elapsed:
> > >> 23.703 s <<< FAILURE! - in org.apache.calcite.test.JdbcTest (MySQL)
> > >> [ERROR] Tests run: 290, Failures: 0, Errors: 1, Skipped: 21, Time
> > elapsed:
> > >> 34.468 s <<< FAILURE! - in org.apache.calcite.test.JdbcTest (Postgres)
> > >> [ERROR] Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time
> elapsed:
> > >> 1.478 s <<< FAILURE! - in org.apache.calcite.test.JdbcAdapterTest
> > >> (Postgres)
> > >> [ERROR] Tests run: 234, Failures: 16, Errors: 6, Skipped: 0, Time
> > elapsed:
> > >> 52.406 s <<< FAILURE! - in org.apache.calcite.test.DruidAdapterIT
> > (Druid)
> > >> [ERROR] Tests run: 31, Failures: 2, Errors: 0, Skipped: 6, Time
> elapsed:
> > >> 3.236 s <<< FAILURE! - in org.apache.calcite.test.MongoAdapterIT
> > (MongoDB)
> > >> -run tests on downstream project KO
> > >> The errors occur due to the simplification of a filter =($0, false) to
> > >> NOT($0) ($0 is boolean). The transformation is valid so in principle
> the
> > >> tests should not fail. However it makes me wonder if adding negation
> is
> > >> really a simplification. If I want to push this expression into an
> > index
> > >> (e.g., B+Tree) I would have to rewrite it again to something
> equivalent
> > to
> > >> =($0, false) since many types of indexes do not support negative
> > >> conditions.
> > >&g
Re: Druid/MongoDB Integration test failures was: [VOTE] Release apache-calcite-1.19.0 (release candidate 1)
For the calcite-test-dataset vm, the docs say you can halt/up the VM. It turns out that Druid doesn't restart on up and MongoDB fails to start due to /var/run/mongodb missing. /var/run is symlinked to /run and /run is mounted as tmpfs so the folders are cleared on a restart. I don't know if this is what is causing the failures you saw but it was causing issues with the "timeout" issues I saw. I am rebuilding the VM and checking the Druid / MongoDB integration tests individually. Kevin Risden On Mon, Mar 18, 2019 at 1:43 PM Kevin Risden wrote: > Stamatis - Can you open JIRA cases for the Druid and MongoDB integration > test failures with details? > > It would be good to track them down not sure if they would block the > release depending on the errors. I seem to have an issue with my > calcite-test-dataset vm currently since getting timeout errors for Mongo > and Druid. I'll see if I can track them down but would be good to see what > the failure details are. > > I did not see the MySQL test failure. I could have missed the > Druid/MongoDB integration test failures since the integration test run > stopped at Postgres. > > Kevin Risden > > > On Mon, Mar 18, 2019 at 12:09 PM Stamatis Zampetakis > wrote: > >> System A: MacOS 10.13.6, jdk9, maven 3.5.2 >> System B: Ubuntu 18.04LTS, jdk1.8.0_192, maven 3.5.3 >> >> -run unit tests (mvn clean install) on staged sources and git repo OK >> -checked signatures and checksums OK >> -went quickly over release note OK >> -run integration tests (mvn -Dtest=foo -DfailIfNoTests=false -Pit verify >> -fn) KO >> A brief summary of the errors is given below: >> [ERROR] Tests run: 290, Failures: 1, Errors: 0, Skipped: 21, Time elapsed: >> 23.703 s <<< FAILURE! - in org.apache.calcite.test.JdbcTest (MySQL) >> [ERROR] Tests run: 290, Failures: 0, Errors: 1, Skipped: 21, Time elapsed: >> 34.468 s <<< FAILURE! - in org.apache.calcite.test.JdbcTest (Postgres) >> [ERROR] Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: >> 1.478 s <<< FAILURE! - in org.apache.calcite.test.JdbcAdapterTest >> (Postgres) >> [ERROR] Tests run: 234, Failures: 16, Errors: 6, Skipped: 0, Time elapsed: >> 52.406 s <<< FAILURE! - in org.apache.calcite.test.DruidAdapterIT (Druid) >> [ERROR] Tests run: 31, Failures: 2, Errors: 0, Skipped: 6, Time elapsed: >> 3.236 s <<< FAILURE! - in org.apache.calcite.test.MongoAdapterIT (MongoDB) >> -run tests on downstream project KO >> The errors occur due to the simplification of a filter =($0, false) to >> NOT($0) ($0 is boolean). The transformation is valid so in principle the >> tests should not fail. However it makes me wonder if adding negation is >> really a simplification. If I want to push this expression into an index >> (e.g., B+Tree) I would have to rewrite it again to something equivalent to >> =($0, false) since many types of indexes do not support negative >> conditions. >> >> My vote is 0 (non-binding) for two reasons: >> (i) there are integration tests failing for which we have not identified >> the reason (excluding tests in Postgres) and may hide regressions; >> (ii) the simplification behavior described above may cause problems in >> certain use-cases. >> >> Στις Παρ, 15 Μαρ 2019 στις 9:45 μ.μ., ο/η Michael Mior >> έγραψε: >> >> > +1 (binding) checked hashes and signature, compiled and ran tests and >> > a RAT check. >> > -- >> > Michael Mior >> > mm...@apache.org >> > >> > Le ven. 15 mars 2019 à 10:38, >> Kevin Risden >> a écrit : >> > > >> > > Hi all, >> > > >> > > I have created a build for Apache Calcite 1.19.0, release candidate 1. >> > > >> > > Thanks to everyone who has contributed to this release. >> > > >> > > Since RC 0, we have fixed the following issues: >> > > * [CALCITE-2925] Exclude maven-wrapper.jar from source distribution >> > > >> > > You can read the release notes here: >> > > >> https://github.com/apache/calcite/blob/branch-1.19/site/_docs/history.md >> > > >> > > The commit to be voted upon: >> > > >> > >> https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=ad11340e5c5abddaa6f2729c9faa2043c4643a8d >> > > >> > > Its hash is ad11340e5c5abddaa6f2729c9faa2043c4643a8d. >> > > >> > > The artifacts to be voted on are located here: >> > > >> > >> https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.19.0-rc1/ >&
Druid/MongoDB Integration test failures was: [VOTE] Release apache-calcite-1.19.0 (release candidate 1)
Stamatis - Can you open JIRA cases for the Druid and MongoDB integration test failures with details? It would be good to track them down not sure if they would block the release depending on the errors. I seem to have an issue with my calcite-test-dataset vm currently since getting timeout errors for Mongo and Druid. I'll see if I can track them down but would be good to see what the failure details are. I did not see the MySQL test failure. I could have missed the Druid/MongoDB integration test failures since the integration test run stopped at Postgres. Kevin Risden On Mon, Mar 18, 2019 at 12:09 PM Stamatis Zampetakis wrote: > System A: MacOS 10.13.6, jdk9, maven 3.5.2 > System B: Ubuntu 18.04LTS, jdk1.8.0_192, maven 3.5.3 > > -run unit tests (mvn clean install) on staged sources and git repo OK > -checked signatures and checksums OK > -went quickly over release note OK > -run integration tests (mvn -Dtest=foo -DfailIfNoTests=false -Pit verify > -fn) KO > A brief summary of the errors is given below: > [ERROR] Tests run: 290, Failures: 1, Errors: 0, Skipped: 21, Time elapsed: > 23.703 s <<< FAILURE! - in org.apache.calcite.test.JdbcTest (MySQL) > [ERROR] Tests run: 290, Failures: 0, Errors: 1, Skipped: 21, Time elapsed: > 34.468 s <<< FAILURE! - in org.apache.calcite.test.JdbcTest (Postgres) > [ERROR] Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: > 1.478 s <<< FAILURE! - in org.apache.calcite.test.JdbcAdapterTest > (Postgres) > [ERROR] Tests run: 234, Failures: 16, Errors: 6, Skipped: 0, Time elapsed: > 52.406 s <<< FAILURE! - in org.apache.calcite.test.DruidAdapterIT (Druid) > [ERROR] Tests run: 31, Failures: 2, Errors: 0, Skipped: 6, Time elapsed: > 3.236 s <<< FAILURE! - in org.apache.calcite.test.MongoAdapterIT (MongoDB) > -run tests on downstream project KO > The errors occur due to the simplification of a filter =($0, false) to > NOT($0) ($0 is boolean). The transformation is valid so in principle the > tests should not fail. However it makes me wonder if adding negation is > really a simplification. If I want to push this expression into an index > (e.g., B+Tree) I would have to rewrite it again to something equivalent to > =($0, false) since many types of indexes do not support negative > conditions. > > My vote is 0 (non-binding) for two reasons: > (i) there are integration tests failing for which we have not identified > the reason (excluding tests in Postgres) and may hide regressions; > (ii) the simplification behavior described above may cause problems in > certain use-cases. > > Στις Παρ, 15 Μαρ 2019 στις 9:45 μ.μ., ο/η Michael Mior > έγραψε: > > > +1 (binding) checked hashes and signature, compiled and ran tests and > > a RAT check. > > -- > > Michael Mior > > mm...@apache.org > > > > Le ven. 15 mars 2019 à 10:38, > Kevin Risden > a écrit : > > > > > > Hi all, > > > > > > I have created a build for Apache Calcite 1.19.0, release candidate 1. > > > > > > Thanks to everyone who has contributed to this release. > > > > > > Since RC 0, we have fixed the following issues: > > > * [CALCITE-2925] Exclude maven-wrapper.jar from source distribution > > > > > > You can read the release notes here: > > > > https://github.com/apache/calcite/blob/branch-1.19/site/_docs/history.md > > > > > > The commit to be voted upon: > > > > > > https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=ad11340e5c5abddaa6f2729c9faa2043c4643a8d > > > > > > Its hash is ad11340e5c5abddaa6f2729c9faa2043c4643a8d. > > > > > > The artifacts to be voted on are located here: > > > > > > https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.19.0-rc1/ > > > > > > The hashes of the artifacts are as follows: > > > src.tar.gz.sha256 > > > 8dbe7e81d955019d78e7de270089fb42726c827f719bfd5a5d11f734fac7face > > > > > > A staged Maven repository is available for review at: > > > > > > https://repository.apache.org/content/repositories/orgapachecalcite-1055/ > > > > > > Release artifacts are signed with the following key: > > > https://people.apache.org/keys/committer/krisden.asc > > > > > > Please vote on releasing this package as Apache Calcite 1.19.0. > > > > > > The vote is open for the next 96 hours (due to the weekend) and passes > > if a > > > majority of > > > at least three +1 PMC votes are cast. > > > > > > [ ] +1 Release this package as Apache Calcite 1.19.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) > > > > > > Kevin Risden > > >
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Vote on RC1. The mvnw jar file was removed. Including the mvnw jar was a change from previous releases. Other binary files have been in previous releases since they are needed to build/test Calcite. Kevin Risden On Mon, Mar 18, 2019 at 11:58 AM Andrei Sereda wrote: > Hello, > > Can one vote on RC 1 (separate thread) or should we wait on decision > wherever having jar files in calcite source distribution is acceptable ? > > On Fri, Mar 15, 2019 at 4:08 PM Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > > > Julian> Lastly, this .jar file is non-essential. The release builds > > just fine without it. > > > > The use of consistent build tool versions would reduce risks. > > For instance: Maven 3.6.1-SNAPSHOT might happen to build Calcite "just > > fine" yet it could silently corrupt something. > > Then ./mvnw does not verify download integrity, so it makes > > build/release less secure. > > > > Why take those risks? > > How can I validate calcite.jar artifacts that are uploaded to Maven > > repository? Which tool could I use to validate that jars match the > > expected ones? > > Can I vote for source artifacts only and explicitly veto binary jars > > on a basis of "I can't validate wha's inside"? > > > > Even though Maven does not support wrapper natively, the case for > > wrapper would be even more important when we use Gradle. > > > > I see a couple of options: > > A) Include maven-wrapper.jar, and put its expected SHA256 side by > > side. We don't update the file often, so "IP and/or tampering" could > > be checked by verifying SHA for the jar file. > > > > B) We could include maven-wrapper in a source form and build it during > > the very first mvnw call. All the *.java files for maven-wrapper sum > > up to 70KiB which is just tiny. > > A single JdbcTest.jar is 350KiB. > > > > Any thoughts? > > ^^ The question above is quite real and I guess the answer would be > > pretty much reused for Gradle-based build. > > > > Julian> Since we have created them, and they are available nowhere else, > > they > > Julian> belong in the source release. > > > > I don't think we created fontawesome-webfont.ttf, did we? > > Technically speaking, calcite/site/fonts is 500+KiB which does look > > like binary files. > > > > Julian> Code is different. The textual source is editable, but the object > > Julian> files (in this case the .class files in the .jar) are not. > > > > As you know, "TrueType systems include a virtual machine that > > executes programs inside the font", so *.ttf is an object file. > > There are CVEs for TTF processing. > > > > Even though it might sound like a stretch, I don't quite buy "having > > consistent build system is not important" kind of conclusions. > > > > Vladimir > > >
[VOTE] Release apache-calcite-1.19.0 (release candidate 1)
Hi all, I have created a build for Apache Calcite 1.19.0, release candidate 1. Thanks to everyone who has contributed to this release. Since RC 0, we have fixed the following issues: * [CALCITE-2925] Exclude maven-wrapper.jar from source distribution You can read the release notes here: https://github.com/apache/calcite/blob/branch-1.19/site/_docs/history.md The commit to be voted upon: https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=ad11340e5c5abddaa6f2729c9faa2043c4643a8d Its hash is ad11340e5c5abddaa6f2729c9faa2043c4643a8d. The artifacts to be voted on are located here: https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.19.0-rc1/ The hashes of the artifacts are as follows: src.tar.gz.sha256 8dbe7e81d955019d78e7de270089fb42726c827f719bfd5a5d11f734fac7face A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachecalcite-1055/ Release artifacts are signed with the following key: https://people.apache.org/keys/committer/krisden.asc Please vote on releasing this package as Apache Calcite 1.19.0. The vote is open for the next 96 hours (due to the weekend) and passes if a majority of at least three +1 PMC votes are cast. [ ] +1 Release this package as Apache Calcite 1.19.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) Kevin Risden
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
I am canceling the vote due to https://issues.apache.org/jira/browse/CALCITE-2925 Thanks to all who voted. I should have a new RC out shortly. Kevin Risden On Fri, Mar 15, 2019 at 9:53 AM Kevin Risden wrote: > I think the difference is that the files you listed Vladimir are needed to > rebuild (compile and test) the project. maven-wrapper.jar is not needed > since mvnw will download it as needed. > > Kevin Risden > > > On Fri, Mar 15, 2019 at 3:07 AM Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > >> Julian> maven-wrapper.jar is a binary file, and we cannot have binary >> files in source distributions. >> >> Hey, Julian, that is a great finding! >> Can you please clarify if the following binary files count towards -1 as >> well? >> >> site/img/pie-chart.png >> site/img/cake.jpg >> site/img/pb-calcite-140.png >> site/img/pb-calcite-240.png >> site/img/powered-by.png >> site/img/window-types.png >> site/img/logo.png >> site/img/feather.png >> site/fonts/fontawesome-webfont.ttf >> site/fonts/fontawesome-webfont.woff >> site/fonts/fontawesome-webfont.eot >> file/src/test/resources/sales-csv/EMPS.csv.gz >> example/csv/src/test/resources/sales/EMPS.csv.gz >> >> Vladimir >> >
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
I think the difference is that the files you listed Vladimir are needed to rebuild (compile and test) the project. maven-wrapper.jar is not needed since mvnw will download it as needed. Kevin Risden On Fri, Mar 15, 2019 at 3:07 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Julian> maven-wrapper.jar is a binary file, and we cannot have binary > files in source distributions. > > Hey, Julian, that is a great finding! > Can you please clarify if the following binary files count towards -1 as > well? > > site/img/pie-chart.png > site/img/cake.jpg > site/img/pb-calcite-140.png > site/img/pb-calcite-240.png > site/img/powered-by.png > site/img/window-types.png > site/img/logo.png > site/img/feather.png > site/fonts/fontawesome-webfont.ttf > site/fonts/fontawesome-webfont.woff > site/fonts/fontawesome-webfont.eot > file/src/test/resources/sales-csv/EMPS.csv.gz > example/csv/src/test/resources/sales/EMPS.csv.gz > > Vladimir >
[jira] [Created] (CALCITE-2925) Exclude maven-wrapper.jar from source distribution
Kevin Risden created CALCITE-2925: - Summary: Exclude maven-wrapper.jar from source distribution Key: CALCITE-2925 URL: https://issues.apache.org/jira/browse/CALCITE-2925 Project: Calcite Issue Type: Task Reporter: Kevin Risden Assignee: Kevin Risden Fix For: 1.19.0 During the 1.19.0 release [~julianhyde] found that the Maven wrapper jar (.mvn/wrapper/maven-wrapper.jar) is included in the source distribution. We should exclude it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
> > maven-wrapper.jar is a binary file, and we cannot have binary files in > source distributions. (Note that ./mvnw can bootstrap just fine without it. > Also note that it is not checked into git — I guess it is created during > the release build process.) > Hmmm that is interesting. ./mvnw downloads the .mvn/wrapper/maven-wrapper.jar file. The release steps say to use ./mvnw (ie: ./mvnw -DskipTests -Papache-release release:perform 2>&1 | tee /tmp/perform.log) so not sure if there is something I need to do differently or needs to be figured out to ensure the .mvn directory is not included in the source distribution. Kevin Risden On Thu, Mar 14, 2019 at 8:56 PM Julian Hyde wrote: > PS Huge thank you to Kevin for being release manager. This has been one of > our most complex releases, and I know that Kevin has put in a massive > effort to get the release this far. I hope the process is over soon! > > > On Mar 14, 2019, at 5:51 PM, Julian Hyde wrote: > > > > -1 due to .mvn/wrapper/maven-wrapper.jar > > > > maven-wrapper.jar is a binary file, and we cannot have binary files in > source distributions. (Note that ./mvnw can bootstrap just fine without it. > Also note that it is not checked into git — I guess it is created during > the release build process.) > > > > Everything else was fine. Checked hashes, KEYS, LICENSE, NOTICE, README; > checked that contents of tar match git; compiled and ran tests using JDK 11 > on Ubuntu linux. > > > > Julian > > > > > >> On Mar 14, 2019, at 10:30 AM, Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > >> > >> +1 (binding) > >> > >> Checksum matches, the code compiles. > >> Release notes look ok. > >> > >> Thanks, Kevin > >> > >> Vladimir > > > >
[VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Hi all, I have created a build for Apache Calcite 1.19.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/blob/branch-1.19/site/_docs/history.md The commit to be voted upon: https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=a08c36fb0284ad121040c336e7d75001019f3495 Its hash is a08c36fb0284ad121040c336e7d75001019f3495. The artifacts to be voted on are located here: https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.19.0-rc0/ The hashes of the artifacts are as follows: src.tar.gz.sha256 a04bfb1bac830e57475dffdbf5f0c3a797c358460d240f6203c929bac61b47ae A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachecalcite-1053/ Release artifacts are signed with the following key: https://people.apache.org/keys/committer/krisden.asc Please vote on releasing this package as Apache Calcite 1.19.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.19.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) Kevin Risden
Re: calcite https://issues.apache.org/jira/browse/CALCITE-759
It looks like you might have worked on this. If you follow the contributing page it walks through creating a pull request: https://calcite.apache.org/develop/#contributing The PR will automatically get linked to the JIRA. Kevin Risden On Thu, Mar 14, 2019 at 12:04 PM zxdrmz wrote: > Hi All! > > I'm working on the TO_TIMESTAMP function implementation. I had added an > sub-task for this work (https://issues.apache.org/jira/browse/CALCITE-2919 > ) > > I'm new to Calcite, so I don't expect everything to be done in the right > way and I will be grateful if someone will take a look. > > https://travis-ci.org/Stabmeqt/calcite/builds/501563894 - travis build > (git > commit can be found inside) > > < > https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail > > > Без > вирусов. www.avast.com > < > https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >
Re: Integration Test failures - JdbcTest and JdbcAdapterTest
Stamatis - Thanks for looking into this!
I'm not sure the integration test against postgres has been run recently. I
went back to branch-1.18 and get the AbstractMethodError errors identified
here: CALCITE-2732 - Upgrade postgresql driver version. CALCITE-2732 didn't
upgrade the Postgres driver version but changed from JDBC 3 to JDBC 4.1 of
the driver.
I was going to try to bisect but that may not be possible since can't run
the integration tests with branch-1.18 due to CALCITE-2732.
So I guess the question is best way to move forward from here. Here are the
options I think:
- Figure out if something changed in 1.19.0 in relation to parenthesis
- Would require testing branch-1.18 with CALCITE-2732 applied
- Test against Postgres 9.6 instead of 9.3
- Would require upgrading calcite-test-dataset vm to Postgres 9.6
I am leaning towards fixing the parenthesis (regardless if the change was
introduced in 1.19.0 or not.) It seems broken to rely on underlying DB to
have correct operator precedence.
I opened CALCITE-2918 to track this further.
Kevin Risden
On Tue, Mar 12, 2019 at 3:52 PM Stamatis Zampetakis
wrote:
> My understanding so far regarding the first problem.
>
> The query plan is the following:
>
> JdbcToEnumerableConverter
> JdbcFilter(condition=[AND(OR(IS NOT NULL($3), IS NOT NULL($3)), IS NOT
> TRUE(=($3, $3)))])
> JdbcTableScan(table=[[foodmart, employee]])
>
> and the SQL query which is send to Postgres is the one below:
>
> SELECT *
> FROM "foodmart"."employee"
> WHERE ("last_name" IS NOT NULL OR "last_name" IS NOT NULL) AND "last_name"
> = "last_name" IS NOT TRUE
>
> The last part of the where clause does not have parentheses so operator
> precedence will take effect.
>
> In Postgres 9.3, which is the one that we use in integration testing, IS
> operator has higher precedence than = [1], which leads to incorrectly
> interpreting the expression as
>
> ("last_name" IS NOT NULL OR "last_name" IS NOT NULL) AND ("last_name" =
> ("last_name" IS NOT TRUE)).
>
> In later versions of Postgres, e.g., Postgres 9.6, the precedence is
> differenent [2] with = having higher precedence than IS so I suppose that
> if we try the same query in another version of Postgres it will run without
> problem as it happens to be the case for MySQL.
>
> I guess between 1.18 and 1.19 we have changed something in terms of
> operator precedence or consideration of parentheses when writting the SQL
> query based on a dialect. Apart from that if we don't parenthesize
> systematically it means that for different versions of postgres we have to
> handle such differences somehow.
>
> I cannot look more now, so if somebody else wants to take it from here feel
> free.
>
> Best,
> Stamatis
>
> [1] https://www.postgresql.org/docs/9.3/sql-syntax-lexical.html
> [2] https://www.postgresql.org/docs/9.6/sql-syntax-lexical.html
>
>
> Στις Τρί, 12 Μαρ 2019 στις 4:48 μ.μ., ο/η Stamatis Zampetakis <
> zabe...@gmail.com> έγραψε:
>
> > If I find some time, I will try to look this evening.
> >
> > Στις Τρί, 12 Μαρ 2019 στις 4:26 μ.μ., ο/η Kevin Risden <
> kris...@apache.org>
> > έγραψε:
> >
> >> Bump - Any ideas on the postgres failure?
> >>
> >> Kevin Risden
> >>
> >>
> >> On Mon, Mar 11, 2019 at 11:51 AM Kevin Risden
> wrote:
> >>
> >> > It looks like there are 2 failures so far when running the integration
> >> > tests (
> >> > https://calcite.apache.org/docs/howto.html#running-integration-tests)
> >> >
> >> > 1. I'm not sure about the JdbcTest and what causes the failure. The
> >> error
> >> > is an exception from postgres and not from Calcite itself. Can anyone
> >> help
> >> > with determine the cause of this test failure?
> >> >
> >> > 2. For the other test, I think the JdbcAdapterTest is missing the
> >> ":NULL"
> >> > part after null that was changed as part of CALCITE-2454.
> >> >
> >> > Partial output from the test run is below:
> >> >
> >> > ./mvnw verify -Pit
> >> >
> >> > [INFO] ---
> >> > [INFO] T E S T S
> >> > [INFO] ---
> >> > [INFO] Running org.apache.calcite.test.JdbcTest
> >> > 2019-03-11 11:23:41,539 [main] INFO - open start - state modified
> >> > 2019-03-11 11:23:41,555 [main] INFO - Checkpoint start
> >> > 2019-03-11 11:2
[jira] [Created] (CALCITE-2918) Integration tests against postgres are broken
Kevin Risden created CALCITE-2918: - Summary: Integration tests against postgres are broken Key: CALCITE-2918 URL: https://issues.apache.org/jira/browse/CALCITE-2918 Project: Calcite Issue Type: Bug Reporter: Kevin Risden Fix For: 1.19.0 As part of the release process, integration testing against postgres found a failure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2916) Upgrade jackson to 2.9.8
Kevin Risden created CALCITE-2916: - Summary: Upgrade jackson to 2.9.8 Key: CALCITE-2916 URL: https://issues.apache.org/jira/browse/CALCITE-2916 Project: Calcite Issue Type: Bug Reporter: Kevin Risden Assignee: Kevin Risden Fix For: 1.19.0 Currently Jackson is on 2.9.6. We should upgrade to Jackson 2.9.8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Integration Test failures - JdbcTest and JdbcAdapterTest
Bump - Any ideas on the postgres failure?
Kevin Risden
On Mon, Mar 11, 2019 at 11:51 AM Kevin Risden wrote:
> It looks like there are 2 failures so far when running the integration
> tests (
> https://calcite.apache.org/docs/howto.html#running-integration-tests)
>
> 1. I'm not sure about the JdbcTest and what causes the failure. The error
> is an exception from postgres and not from Calcite itself. Can anyone help
> with determine the cause of this test failure?
>
> 2. For the other test, I think the JdbcAdapterTest is missing the ":NULL"
> part after null that was changed as part of CALCITE-2454.
>
> Partial output from the test run is below:
>
> ./mvnw verify -Pit
>
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.apache.calcite.test.JdbcTest
> 2019-03-11 11:23:41,539 [main] INFO - open start - state modified
> 2019-03-11 11:23:41,555 [main] INFO - Checkpoint start
> 2019-03-11 11:23:41,555 [main] INFO - Checkpoint end - txts: 25
> [ERROR] Tests run: 290, Failures: 0, Errors: 1, Skipped: 21, Time elapsed:
> 65.154 s <<< FAILURE! - in org.apache.calcite.test.JdbcTest
> [ERROR] testIsNotDistinctInFilter(org.apache.calcite.test.JdbcTest) Time
> elapsed: 0.041 s <<< ERROR!
> java.sql.SQLException:
> Error while executing SQL "select *
> from "foodmart"."employee" as e1
> where e1."last_name" is distinct from e1."last_name"": While executing
> SQL [SELECT *
> FROM "foodmart"."employee"
> WHERE ("last_name" IS NOT NULL OR "last_name" IS NOT NULL) AND "last_name"
> = "last_name" IS NOT TRUE] on JDBC sub-schema
> at
> org.apache.calcite.test.JdbcTest.testIsNotDistinctInFilter(JdbcTest.java:1585)
> Caused by: java.lang.RuntimeException:
> While executing SQL [SELECT *
> FROM "foodmart"."employee"
> WHERE ("last_name" IS NOT NULL OR "last_name" IS NOT NULL) AND "last_name"
> = "last_name" IS NOT TRUE] on JDBC sub-schema
> at
> org.apache.calcite.test.JdbcTest.testIsNotDistinctInFilter(JdbcTest.java:1585)
> Caused by: org.postgresql.util.PSQLException:
> ERROR: argument of IS NOT TRUE must be type boolean, not type character
> varying
> Position: 114
> at
> org.apache.calcite.test.JdbcTest.testIsNotDistinctInFilter(JdbcTest.java:1585)
>
> [INFO] Running org.apache.calcite.test.JdbcAdapterTest
> [ERROR] Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 2.605 s <<< FAILURE! - in org.apache.calcite.test.JdbcAdapterTest
> [ERROR] testOverDisallowPartial(org.apache.calcite.test.JdbcAdapterTest)
> Time elapsed: 0.015 s <<< FAILURE!
> java.lang.AssertionError:
>
> Expected: a string containing "PLAN=JdbcToEnumerableConverter\n
> JdbcProject(store_id=[$0], account_id=[$1], exp_date=[$2], time_id=[$3],
> category_id=[$4], currency_id=[$5], amount=[$6],
> last_version=[CASE(>=(COUNT() OVER (PARTITION BY $1 ORDER BY $3 ROWS
> BETWEEN 3 PRECEDING AND CURRENT ROW), 2), LAST_VALUE($3) OVER (PARTITION BY
> $1 ORDER BY $3 ROWS BETWEEN 3 PRECEDING AND CURRENT ROW), null)])\n
> JdbcTableScan(table=[[foodmart, expense_fact]])\n"
> but: was "PLAN=JdbcToEnumerableConverter\n
> JdbcProject(store_id=[$0], account_id=[$1], exp_date=[$2], time_id=[$3],
> category_id=[$4], currency_id=[$5], amount=[$6],
> last_version=[CASE(>=(COUNT() OVER (PARTITION BY $1 ORDER BY $3 ROWS
> BETWEEN 3 PRECEDING AND CURRENT ROW), 2), LAST_VALUE($3) OVER (PARTITION BY
> $1 ORDER BY $3 ROWS BETWEEN 3 PRECEDING AND CURRENT ROW), null:NULL)])\n
> JdbcTableScan(table=[[foodmart, expense_fact]])\n\n"
> at
> org.apache.calcite.test.JdbcAdapterTest.testOverDisallowPartial(JdbcAdapterTest.java:572)
>
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] JdbcAdapterTest.testOverDisallowPartial:572
> Expected: a string containing "PLAN=JdbcToEnumerableConverter\n
> JdbcProject(store_id=[$0], account_id=[$1], exp_date=[$2], time_id=[$3],
> category_id=[$4], currency_id=[$5], amount=[$6],
> last_version=[CASE(>=(COUNT() OVER (PARTITION BY $1 ORDER BY $3 ROWS
> BETWEEN 3 PRECEDING AND CURRENT ROW), 2), LAST_VALUE($3) OVER (PARTITION BY
> $1 ORDER BY $3 ROWS BETWEEN 3 PRECEDING AND CURRENT ROW), null)])\n
> JdbcTableScan(table=[[foodmart, expense_fact]])\n"
> but: was "PLAN=JdbcToEnumerableConverter\n
> JdbcProject(store_id=[$0], account_id=[$1], exp_date=[$2], time_id=[$3],
> category_id=[$4], currency_id=[$5], amount=[$6],
> last_version=[CASE(>=(COUNT() OVER (PARTITION BY $1 ORDER BY $3 ROWS
> BETWEEN 3 PRECEDING AND CURRENT ROW), 2), LAST_VALUE($3) OVER (PARTITION BY
> $1 ORDER BY $3 ROWS BETWEEN 3 PRECEDING AND CURRENT ROW), null:NULL)])\n
> JdbcTableScan(table=[[foodmart, expense_fact]])\n\n"
> [ERROR] Errors:
> [ERROR] JdbcTest.testIsNotDistinctInFilter:1585 » SQL Error while
> executing SQL "selec...
> [INFO]
> [ERROR] Tests run: 326, Failures: 1, Errors: 1, Skipped: 21
>
>
> Kevin Risden
>
Integration Test failures - JdbcTest and JdbcAdapterTest
It looks like there are 2 failures so far when running the integration
tests (https://calcite.apache.org/docs/howto.html#running-integration-tests)
1. I'm not sure about the JdbcTest and what causes the failure. The error
is an exception from postgres and not from Calcite itself. Can anyone help
with determine the cause of this test failure?
2. For the other test, I think the JdbcAdapterTest is missing the ":NULL"
part after null that was changed as part of CALCITE-2454.
Partial output from the test run is below:
./mvnw verify -Pit
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running org.apache.calcite.test.JdbcTest
2019-03-11 11:23:41,539 [main] INFO - open start - state modified
2019-03-11 11:23:41,555 [main] INFO - Checkpoint start
2019-03-11 11:23:41,555 [main] INFO - Checkpoint end - txts: 25
[ERROR] Tests run: 290, Failures: 0, Errors: 1, Skipped: 21, Time elapsed:
65.154 s <<< FAILURE! - in org.apache.calcite.test.JdbcTest
[ERROR] testIsNotDistinctInFilter(org.apache.calcite.test.JdbcTest) Time
elapsed: 0.041 s <<< ERROR!
java.sql.SQLException:
Error while executing SQL "select *
from "foodmart"."employee" as e1
where e1."last_name" is distinct from e1."last_name"": While executing
SQL [SELECT *
FROM "foodmart"."employee"
WHERE ("last_name" IS NOT NULL OR "last_name" IS NOT NULL) AND "last_name"
= "last_name" IS NOT TRUE] on JDBC sub-schema
at
org.apache.calcite.test.JdbcTest.testIsNotDistinctInFilter(JdbcTest.java:1585)
Caused by: java.lang.RuntimeException:
While executing SQL [SELECT *
FROM "foodmart"."employee"
WHERE ("last_name" IS NOT NULL OR "last_name" IS NOT NULL) AND "last_name"
= "last_name" IS NOT TRUE] on JDBC sub-schema
at
org.apache.calcite.test.JdbcTest.testIsNotDistinctInFilter(JdbcTest.java:1585)
Caused by: org.postgresql.util.PSQLException:
ERROR: argument of IS NOT TRUE must be type boolean, not type character
varying
Position: 114
at
org.apache.calcite.test.JdbcTest.testIsNotDistinctInFilter(JdbcTest.java:1585)
[INFO] Running org.apache.calcite.test.JdbcAdapterTest
[ERROR] Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
2.605 s <<< FAILURE! - in org.apache.calcite.test.JdbcAdapterTest
[ERROR] testOverDisallowPartial(org.apache.calcite.test.JdbcAdapterTest)
Time elapsed: 0.015 s <<< FAILURE!
java.lang.AssertionError:
Expected: a string containing "PLAN=JdbcToEnumerableConverter\n
JdbcProject(store_id=[$0], account_id=[$1], exp_date=[$2], time_id=[$3],
category_id=[$4], currency_id=[$5], amount=[$6],
last_version=[CASE(>=(COUNT() OVER (PARTITION BY $1 ORDER BY $3 ROWS
BETWEEN 3 PRECEDING AND CURRENT ROW), 2), LAST_VALUE($3) OVER (PARTITION BY
$1 ORDER BY $3 ROWS BETWEEN 3 PRECEDING AND CURRENT ROW), null)])\n
JdbcTableScan(table=[[foodmart, expense_fact]])\n"
but: was "PLAN=JdbcToEnumerableConverter\n JdbcProject(store_id=[$0],
account_id=[$1], exp_date=[$2], time_id=[$3], category_id=[$4],
currency_id=[$5], amount=[$6], last_version=[CASE(>=(COUNT() OVER
(PARTITION BY $1 ORDER BY $3 ROWS BETWEEN 3 PRECEDING AND CURRENT ROW), 2),
LAST_VALUE($3) OVER (PARTITION BY $1 ORDER BY $3 ROWS BETWEEN 3 PRECEDING
AND CURRENT ROW), null:NULL)])\nJdbcTableScan(table=[[foodmart,
expense_fact]])\n\n"
at
org.apache.calcite.test.JdbcAdapterTest.testOverDisallowPartial(JdbcAdapterTest.java:572)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] JdbcAdapterTest.testOverDisallowPartial:572
Expected: a string containing "PLAN=JdbcToEnumerableConverter\n
JdbcProject(store_id=[$0], account_id=[$1], exp_date=[$2], time_id=[$3],
category_id=[$4], currency_id=[$5], amount=[$6],
last_version=[CASE(>=(COUNT() OVER (PARTITION BY $1 ORDER BY $3 ROWS
BETWEEN 3 PRECEDING AND CURRENT ROW), 2), LAST_VALUE($3) OVER (PARTITION BY
$1 ORDER BY $3 ROWS BETWEEN 3 PRECEDING AND CURRENT ROW), null)])\n
JdbcTableScan(table=[[foodmart, expense_fact]])\n"
but: was "PLAN=JdbcToEnumerableConverter\n JdbcProject(store_id=[$0],
account_id=[$1], exp_date=[$2], time_id=[$3], category_id=[$4],
currency_id=[$5], amount=[$6], last_version=[CASE(>=(COUNT() OVER
(PARTITION BY $1 ORDER BY $3 ROWS BETWEEN 3 PRECEDING AND CURRENT ROW), 2),
LAST_VALUE($3) OVER (PARTITION BY $1 ORDER BY $3 ROWS BETWEEN 3 PRECEDING
AND CURRENT ROW), null:NULL)])\nJdbcTableScan(table=[[foodmart,
expense_fact]])\n\n"
[ERROR] Errors:
[ERROR] JdbcTest.testIsNotDistinctInFilter:1585 » SQL Error while
executing SQL "selec...
[INFO]
[ERROR] Tests run: 326, Failures: 1, Errors: 1, Skipped: 21
Kevin Risden
Re: CALCITE-2457. JUnit5 migration.
3. Should I wait for 1.20 release ? Not commenting on the rest of the proposal but will definitely need to wait until after the 1.19.0 release. Kevin Risden On Sun, Mar 10, 2019 at 5:43 AM Muhammad Gelbana wrote: > The only benefit I can think of out of updating JUnit or our maven plugins > in general, is getting closer to have a faster build if we leverage maven's > or JUnit's parallel execution feature. > > Unfortunately it's still experimental for maven and JUnit5. > > But it's a good idea to stay a couple of steps behind rather than having to > do a lot of changes at once. > > Thanks, > Gelbana > > > On Sun, Mar 10, 2019 at 5:32 AM Andrei Sereda wrote: > > > We already require maven 3.5.2 (or newer) > > > > On Sat, Mar 9, 2019, 21:49 YuZhao Chan wrote: > > > > > Maven version 3.6.0 seems a too much new version, now most of the > > > developers use 3.2.x and 3.3.x version maven, i think it will be bad to > > run > > > fail test cases just because the maven version is old. > > > > > > Best, > > > YuZhao Chen > > > 在 2019年3月10日 +0800 AM1:28，Andrei Sereda ，写道： > > > > Greetings, > > > > > > > > > > > > I would like to start a gradual migration of calcite test codebase to > > > > [JUnit5](https://junit.org/junit5/). The plan is to do in several > > steps > > > > outlined below : > > > > > > > > 1. Upgrade maven wrapper to 3.6.0 (surefire plugin needs to work with > > > > JUnit5 >= 2.22.0). Maybe enforce maven 3.6.0 during builds. > > > > 2. Add new dependencies to maven pom (jupiter and vantage). > > > > 3. Migrate all basic tests to new JUnit5 API. Basic in this context > > means > > > > tests without [rules]( > https://github.com/junit-team/junit4/wiki/rules) > > > or > > > > [runners]( > > > > > > > > > > https://github.com/junit-team/junit4/wiki/test-runners#runwith-annotation) > > > > just basic `@Test` / `@Before` / `@Ignore` annotations. Code where I > > can > > > > just apply string/replace and make it work in JUnit5. > > > > 4. Migrate remaining tests (with `@Parameterized` / `@ClassRule` > etc.). > > > For > > > > example, I will have to write custom extensions for existing elastic > / > > > > mongo / cassandra / geode class rules. > > > > > > > > For developers that means you will need to have a reasonably recent > > IDE / > > > > Maven: > > > > 1. For IntelliJ this is >= 2016.2 > > > > 2. For Eclipse this is >= Oxygen.1a (4.7.1a) > > > > 3. For Maven >= 3.6.0 (released on 2018-10-24) > > > > > > > > Questions to fellow calcitians: > > > > > > > > 1. Do you agree with JUnit5 migration ? > > > > 2. Do you agree with the plan ? > > > > 3. Should I wait for 1.20 release ? > > > > 4. Anything I missed ? > > > > > > > > Regards, > > > > Andrei. > > > > > >
Re: [DISCUSS] Towards Calcite 1.19.0
As of this morning, all JIRAs tagged for 1.19.0 have been resolved or moved out to 1.20.0. I will be starting the release steps this morning. Please hold off on commits to master while the 1.19.0 release is happening. Kevin Risden On Wed, Mar 6, 2019 at 9:02 AM Kevin Risden wrote: > It looks like we haven't made any progress (JIRAs have been opened/closed) > towards closing down JIRAs tagged for 1.19.0. There are still 14 (14 on > 2/27) open JIRAs tagged for 1.19.0. > > I will start moving those JIRAs out today to 1.20.0 so I can start to > close those this release. We are getting to mid March at this point since > we keep postponing this release. > > Kevin Risden > > > On Thu, Feb 28, 2019 at 5:55 AM YuZhao Chan wrote: > >> I would help to review some PRs this weekend，especially [1]. Hope to help >> and release some of the burden. >> [1] >> https://issues.apache.org/jira/browse/CALCITE-2018?jql=project%20%3D%20CALCITE%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(EMPTY%2C%20%22next%22)%20AND%20labels%20%3D%20pull-request-available%20ORDER%20BY%20priority%20DESC >> >> Best, >> YuZhao Chan >> 在 2019年2月26日 +0800 AM8:14，Julian Hyde ，写道： >> > Hey everyone. >> > >> > There are 108 open pull requests. What are we going to do about it? >> > >> > Last release I reviewed and committed dozens of pull requests, and I >> burned out. >> > >> > Julian >> > >> > >> > > On Feb 22, 2019, at 1:20 PM, >> Kevin Risden >> wrote: >> > > >> > > Yea I don't mind pushing out the RC towards the end of next week >> (beginning >> > > of March). I'm not in a rush to build the RC. I just picked Monday to >> try >> > > to hit the target of February that was arbitrarily picked in the >> sand. At >> > > this point, the release will most likely happen in early March. >> > > >> > > Kevin Risden >> > > >> > > >> > > On Fri, Feb 22, 2019 at 4:15 PM Julian Hyde wrote: >> > > >> > > > Can you do the RC towards the end of next week? >> > > > >> > > > I only just saw this message - 4 days after you sent it - because >> I’ve >> > > > been fighting down a backlog of 500 Apache messages. There are some >> changes >> > > > I would like to get into the release but I will need a few days. >> > > > >> > > > Julian >> > > > >> > > > >> > > > > On Feb 18, 2019, at 9:56 AM, >> > > > Kevin Risden >> > > > wrote: >> > > > > >> > > > > It looks like there are some PRs to be reviewed and some changes >> to get >> > > > > merged in this week. >> > > > > >> > > > > How does creating the first RC on Monday Feb 25th sound? Does >> that give >> > > > > enough time this week to get changes into Calcite 1.19.0? >> > > > > >> > > > > Kevin Risden >> > > > > >> > > > > >> > > > > On Wed, Feb 13, 2019 at 11:08 AM Zoltan Haindrich >> wrote: >> > > > > >> > > > > > >> > > > > > On 2/13/19 4:24 PM, Julian Hyde wrote: >> > > > > > > Sorry, there’s been a misunderstanding. Let me clarify. I >> didn’t say >> > > > > > that your patches were too small. Or intend to imply it. >> > > > > > > >> > > > > > > When I said “widespread changes for no good reason” - or >> something like >> > > > > > that - I meant changes to the RexNode format due to removing IS >> TRUE >> > > > nodes. >> > > > > > > >> > > > > > > I like small patches, provided each one fixes a well defined >> issue and >> > > > > > has appropriate tests. >> > > > > > >> > > > > > From now on I will try to provide a testcase when opening the >> jira. >> > > > > > Sorry for the misunderstanding, thank you for making it clear! >> > > > > > >> > > > > > > >> > > > > > > Julian >> > > > > > > >> > > > > > > > On Feb 13, 2019, at 3:40 AM, Zoltan Haindrich >> wrote: >> > > > > > > > >> > > > > > > > Hello, >> > > &
[jira] [Created] (CALCITE-2911) Release Calcite 1.19.0
Kevin Risden created CALCITE-2911: - Summary: Release Calcite 1.19.0 Key: CALCITE-2911 URL: https://issues.apache.org/jira/browse/CALCITE-2911 Project: Calcite Issue Type: Task Reporter: Kevin Risden Assignee: Kevin Risden Fix For: 1.19.0 Release Calcite 1.19.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2910) Improve testing of RexSqlStandardConvertletTable
Kevin Risden created CALCITE-2910: - Summary: Improve testing of RexSqlStandardConvertletTable Key: CALCITE-2910 URL: https://issues.apache.org/jira/browse/CALCITE-2910 Project: Calcite Issue Type: Test Reporter: Kevin Risden Fix For: 1.20.0 CALCITE-2767 found that there is a lack of tests around RexSqlStandardConvertletTable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
JIRA Permissions to create 1.20.0 version?
I was looking to move 1.19.0 issues that aren't ready to 1.20.0, but don't have permissions in the CALCITE JIRA project to create a new version. Can this permission be provided? Kevin Risden
Re: [DISCUSS] Towards Calcite 1.19.0
It looks like we haven't made any progress (JIRAs have been opened/closed) towards closing down JIRAs tagged for 1.19.0. There are still 14 (14 on 2/27) open JIRAs tagged for 1.19.0. I will start moving those JIRAs out today to 1.20.0 so I can start to close those this release. We are getting to mid March at this point since we keep postponing this release. Kevin Risden On Thu, Feb 28, 2019 at 5:55 AM YuZhao Chan wrote: > I would help to review some PRs this weekend，especially [1]. Hope to help > and release some of the burden. > [1] > https://issues.apache.org/jira/browse/CALCITE-2018?jql=project%20%3D%20CALCITE%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(EMPTY%2C%20%22next%22)%20AND%20labels%20%3D%20pull-request-available%20ORDER%20BY%20priority%20DESC > > Best, > YuZhao Chan > 在 2019年2月26日 +0800 AM8:14，Julian Hyde ，写道： > > Hey everyone. > > > > There are 108 open pull requests. What are we going to do about it? > > > > Last release I reviewed and committed dozens of pull requests, and I > burned out. > > > > Julian > > > > > > > On Feb 22, 2019, at 1:20 PM, > Kevin Risden > wrote: > > > > > > Yea I don't mind pushing out the RC towards the end of next week > (beginning > > > of March). I'm not in a rush to build the RC. I just picked Monday to > try > > > to hit the target of February that was arbitrarily picked in the sand. > At > > > this point, the release will most likely happen in early March. > > > > > > Kevin Risden > > > > > > > > > On Fri, Feb 22, 2019 at 4:15 PM Julian Hyde wrote: > > > > > > > Can you do the RC towards the end of next week? > > > > > > > > I only just saw this message - 4 days after you sent it - because > I’ve > > > > been fighting down a backlog of 500 Apache messages. There are some > changes > > > > I would like to get into the release but I will need a few days. > > > > > > > > Julian > > > > > > > > > > > > > On Feb 18, 2019, at 9:56 AM, > > > > Kevin Risden > > > > wrote: > > > > > > > > > > It looks like there are some PRs to be reviewed and some changes > to get > > > > > merged in this week. > > > > > > > > > > How does creating the first RC on Monday Feb 25th sound? Does that > give > > > > > enough time this week to get changes into Calcite 1.19.0? > > > > > > > > > > Kevin Risden > > > > > > > > > > > > > > > On Wed, Feb 13, 2019 at 11:08 AM Zoltan Haindrich > wrote: > > > > > > > > > > > > > > > > > On 2/13/19 4:24 PM, Julian Hyde wrote: > > > > > > > Sorry, there’s been a misunderstanding. Let me clarify. I > didn’t say > > > > > > that your patches were too small. Or intend to imply it. > > > > > > > > > > > > > > When I said “widespread changes for no good reason” - or > something like > > > > > > that - I meant changes to the RexNode format due to removing IS > TRUE > > > > nodes. > > > > > > > > > > > > > > I like small patches, provided each one fixes a well defined > issue and > > > > > > has appropriate tests. > > > > > > > > > > > > From now on I will try to provide a testcase when opening the > jira. > > > > > > Sorry for the misunderstanding, thank you for making it clear! > > > > > > > > > > > > > > > > > > > > Julian > > > > > > > > > > > > > > > On Feb 13, 2019, at 3:40 AM, Zoltan Haindrich > wrote: > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > In Hive I'm a little bit behind in upgrading to 1.18 and > although the > > > > > > upgrade would not cause any correctness issues; but in a sense > it's more > > > > > > conservative in doing some simplifications - which could be > interpreted > > > > as > > > > > > regressions; if we take that into account that even the plan > could get > > > > > > worse. > > > > > > > > > > > > > > > > I've a few patches almost ready - they are very small changes > > > > (actually > > > > >
Re: JIRAs and Pull Requests Cleanup
As of now, the open PRs and Calcite JIRAs are close enough to matching (96 vs 98). (There are a few for Avatica in the JIRA query). Thanks all those that helped clean up. Kevin Risden On Thu, Feb 28, 2019 at 4:21 PM Kevin Risden wrote: > One thing that I think would help is to add a Github PR template [1]. We > did this for Apache Knox to help make sure that PRs follow some simple > guidelines. After the gitbox migration, PRs are automatically linked to > JIRA (which is good). I think we just had some PRs prior to gitbox > migration that didn't have the autolink part. > > [1] > https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository > [2] https://issues.apache.org/jira/browse/KNOX-1760 > > Kevin Risden > > > On Thu, Feb 28, 2019 at 4:07 PM Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > >> Francis> Our problem is mainly due to PRs not being reviewed. >> >> Once upon a time I did try to pass over the PRs, and I added some randoms >> here and there. >> I'm not sure what others think of that, however we have: >> >> 17 "returned-with-feedback": >> >> https://github.com/apache/calcite/pulls?q=is%3Apr+is%3Aopen+label%3Areturned-with-feedback >> 6 with pending discussion in JIRA: >> >> https://github.com/apache/calcite/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aopen+label%3Adiscussion-in-jira >> >> I like "LGTM-will-merge-soon" as a soft warning to other committers that >> "hey, either you chime in or I just commit this stuff". >> We have 2 by the way: >> https://github.com/apache/calcite/labels/LGTM-will-merge-soon >> >> Vladimir >> >
Re: JIRAs and Pull Requests Cleanup
One thing that I think would help is to add a Github PR template [1]. We did this for Apache Knox to help make sure that PRs follow some simple guidelines. After the gitbox migration, PRs are automatically linked to JIRA (which is good). I think we just had some PRs prior to gitbox migration that didn't have the autolink part. [1] https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository [2] https://issues.apache.org/jira/browse/KNOX-1760 Kevin Risden On Thu, Feb 28, 2019 at 4:07 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Francis> Our problem is mainly due to PRs not being reviewed. > > Once upon a time I did try to pass over the PRs, and I added some randoms > here and there. > I'm not sure what others think of that, however we have: > > 17 "returned-with-feedback": > > https://github.com/apache/calcite/pulls?q=is%3Apr+is%3Aopen+label%3Areturned-with-feedback > 6 with pending discussion in JIRA: > > https://github.com/apache/calcite/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aopen+label%3Adiscussion-in-jira > > I like "LGTM-will-merge-soon" as a soft warning to other committers that > "hey, either you chime in or I just commit this stuff". > We have 2 by the way: > https://github.com/apache/calcite/labels/LGTM-will-merge-soon > > Vladimir >
Re: JIRAs and Pull Requests Cleanup
Thanks! Kevin Risden On Wed, Feb 27, 2019, 17:55 Stamatis Zampetakis wrote: > I also went over the third page [1]. I am leaving the rest (first and > second) to somebody else :) > > [1] https://github.com/apache/calcite/pulls?page=3=is%3Apr+is%3Aopen > > Στις Πέμ, 28 Φεβ 2019 στις 12:03 π.μ., ο/η Stamatis Zampetakis < > zabe...@gmail.com> έγραψε: > > > Good idea Kevin! > > > > I will give you a hand. I will go over the fourth page [1] of pull > > requests right now. > > > > [1] https://github.com/apache/calcite/pulls?page=4=is%3Apr+is%3Aopen > > > > Στις Τετ, 27 Φεβ 2019 στις 11:13 μ.μ., ο/η Julian Hyde > > > έγραψε: > > > >> +999! > >> > >> > On Feb 27, 2019, at 1:29 PM, Francis Chuang > > >> wrote: > >> > > >> > Thanks for jumping on this, Kevin! > >> > > >> > On 28/02/2019 6:36 am, Kevin Risden wrote: > >> >> There are 105 open pull requests against apache/calcite repo [1]. > >> There are > >> >> only 48 Calcite JIRAs labeled with pull-request-available [2]. > >> >> I'm planning to go through in the next few days and make sure that we > >> have > >> >> PRs that match open JIRAs and are labeled pull-request-available. If > >> there > >> >> are PRs that are open for JIRAs that are closed, planning to close > >> those > >> >> PRs with a comment. > >> >> [1] https://github.com/apache/calcite/pulls > >> >> [2] > >> >> > >> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20CALCITE%20AND%20resolution%20%3D%20Unresolved%20AND%20labels%20%3D%20pull-request-available%20ORDER%20BY%20priority%20DESC > >> >> Kevin Risden > >> > > >> > >> >
JIRAs and Pull Requests Cleanup
There are 105 open pull requests against apache/calcite repo [1]. There are only 48 Calcite JIRAs labeled with pull-request-available [2]. I'm planning to go through in the next few days and make sure that we have PRs that match open JIRAs and are labeled pull-request-available. If there are PRs that are open for JIRAs that are closed, planning to close those PRs with a comment. [1] https://github.com/apache/calcite/pulls [2] https://issues.apache.org/jira/issues/?jql=project%20%3D%20CALCITE%20AND%20resolution%20%3D%20Unresolved%20AND%20labels%20%3D%20pull-request-available%20ORDER%20BY%20priority%20DESC Kevin Risden
Re: [DISCUSS] Towards Calcite 1.19.0
So I looked at the JIRAs tagged for 1.19.0 [1], and there are 14 currently unresolved. 9 have the pull-request-available label. 5 don't. None of the remaining JIRAs are marked as blockers (highest priority is major). I can look through the 9 pull requests tomorrow and see how close they are to being merged. There are quite a few JIRAs with the label pull-request-available, but no fix version on that Jira. 35 by my count [2]. Are there any of these that should be in 1.19.0 but don't have the proper Fix Version 1.19.0 set in Jira? Any concerns with starting the first RC on Monday March 4th? [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20CALCITE%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.19.0%20ORDER%20BY%20priority%20DESC [2] https://issues.apache.org/jira/issues/?jql=project%20%3D%20CALCITE%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(EMPTY%2C%20%22next%22)%20AND%20labels%20%3D%20pull-request-available%20ORDER%20BY%20priority%20DESC Kevin Risden On Tue, Feb 26, 2019 at 11:27 AM Michael Mior wrote: > I've started to review a few myself. Although it doesn't fix the root > of the problem, it would be helpful if people who filed PRs that are > now stale could close those out. It looks like many older PRs are > abandoned and it would be nice to close out any that aren't actively > being worked on. They can always be reopened in the future. > > -- > Michael Mior > mm...@apache.org > > Le lun. 25 févr. 2019 à 19:14, Julian Hyde a écrit : > > > > Hey everyone. > > > > There are 108 open pull requests. What are we going to do about it? > > > > Last release I reviewed and committed dozens of pull requests, and I > burned out. > > > > Julian > > > > > > > On Feb 22, 2019, at 1:20 PM, > Kevin Risden > wrote: > > > > > > Yea I don't mind pushing out the RC towards the end of next week > (beginning > > > of March). I'm not in a rush to build the RC. I just picked Monday to > try > > > to hit the target of February that was arbitrarily picked in the sand. > At > > > this point, the release will most likely happen in early March. > > > > > > Kevin Risden > > > > > > > > > On Fri, Feb 22, 2019 at 4:15 PM Julian Hyde wrote: > > > > > >> Can you do the RC towards the end of next week? > > >> > > >> I only just saw this message - 4 days after you sent it - because I’ve > > >> been fighting down a backlog of 500 Apache messages. There are some > changes > > >> I would like to get into the release but I will need a few days. > > >> > > >> Julian > > >> > > >> > > >>> On Feb 18, 2019, at 9:56 AM, > > >> Kevin Risden > > >> wrote: > > >>> > > >>> It looks like there are some PRs to be reviewed and some changes to > get > > >>> merged in this week. > > >>> > > >>> How does creating the first RC on Monday Feb 25th sound? Does that > give > > >>> enough time this week to get changes into Calcite 1.19.0? > > >>> > > >>> Kevin Risden > > >>> > > >>> > > >>> On Wed, Feb 13, 2019 at 11:08 AM Zoltan Haindrich > wrote: > > >>> > > >>>> > > >>>> On 2/13/19 4:24 PM, Julian Hyde wrote: > > >>>>> Sorry, there’s been a misunderstanding. Let me clarify. I didn’t > say > > >>>> that your patches were too small. Or intend to imply it. > > >>>>> > > >>>>> When I said “widespread changes for no good reason” - or something > like > > >>>> that - I meant changes to the RexNode format due to removing IS TRUE > > >> nodes. > > >>>>> > > >>>>> I like small patches, provided each one fixes a well defined issue > and > > >>>> has appropriate tests. > > >>>> > > >>>> From now on I will try to provide a testcase when opening the jira. > > >>>> Sorry for the misunderstanding, thank you for making it clear! > > >>>> > > >>>>> > > >>>>> Julian > > >>>>> > > >>>>>> On Feb 13, 2019, at 3:40 AM, Zoltan Haindrich > wrote: > > >>>>>> > > >>>>>> Hello, > > >>>>>> > > >>>>>> In Hive I'm a little bit behind in upgrading to 1.18 and although > the > > >>>> u
Re: [DISCUSS] Towards Calcite 1.19.0
Yea I don't mind pushing out the RC towards the end of next week (beginning of March). I'm not in a rush to build the RC. I just picked Monday to try to hit the target of February that was arbitrarily picked in the sand. At this point, the release will most likely happen in early March. Kevin Risden On Fri, Feb 22, 2019 at 4:15 PM Julian Hyde wrote: > Can you do the RC towards the end of next week? > > I only just saw this message - 4 days after you sent it - because I’ve > been fighting down a backlog of 500 Apache messages. There are some changes > I would like to get into the release but I will need a few days. > > Julian > > > > On Feb 18, 2019, at 9:56 AM, > Kevin Risden > wrote: > > > > It looks like there are some PRs to be reviewed and some changes to get > > merged in this week. > > > > How does creating the first RC on Monday Feb 25th sound? Does that give > > enough time this week to get changes into Calcite 1.19.0? > > > > Kevin Risden > > > > > > On Wed, Feb 13, 2019 at 11:08 AM Zoltan Haindrich wrote: > > > >> > >> On 2/13/19 4:24 PM, Julian Hyde wrote: > >>> Sorry, there’s been a misunderstanding. Let me clarify. I didn’t say > >> that your patches were too small. Or intend to imply it. > >>> > >>> When I said “widespread changes for no good reason” - or something like > >> that - I meant changes to the RexNode format due to removing IS TRUE > nodes. > >>> > >>> I like small patches, provided each one fixes a well defined issue and > >> has appropriate tests. > >> > >> From now on I will try to provide a testcase when opening the jira. > >> Sorry for the misunderstanding, thank you for making it clear! > >> > >>> > >>> Julian > >>> > >>>> On Feb 13, 2019, at 3:40 AM, Zoltan Haindrich wrote: > >>>> > >>>> Hello, > >>>> > >>>> In Hive I'm a little bit behind in upgrading to 1.18 and although the > >> upgrade would not cause any correctness issues; but in a sense it's more > >> conservative in doing some simplifications - which could be interpreted > as > >> regressions; if we take that into account that even the plan could get > >> worse. > >>>> > >>>> I've a few patches almost ready - they are very small changes > (actually > >> Julian mentioned that they are kinda too small, so next time I will not > be > >> opening separate jiras for them) > >>>> > >>>> I will finish them and launch a custom Hive test with the latest > master > >> to see if there are any new issues coming from that direction. > >>>> I should get the results for it by tomorrow. > >>>> > >>>> cheers, > >>>> Zoltan > >>>> > >>>> > >>>>> On 2/12/19 11:30 PM, Stamatis Zampetakis wrote: > >>>>> I was not suggesting changing the release process. I wanted just to > >>>>> highlight the fact that if the aforementioned tickets are not part of > >> 1.19 > >>>>> I will have to create an unofficial bundle which includes them in > >> order to > >>>>> keep the downstream project working. Sorry for the confusion. > >>>>> Στις Τρί, 12 Φεβ 2019 στις 8:56 μ.μ., ο/η Julian Hyde < > >> jh...@apache.org> > >>>>> έγραψε: > >>>>>> Stamatis, > >>>>>> > >>>>>> We’ve so far managed to avoid making patch releases. It keeps life > >> simpler > >>>>>> if all releases are from the main line. And simple is important, > >> given that > >>>>>> there are no salaried release or QA engineers working on Calcite. > >>>>>> > >>>>>> But as part of that contract, we commit to making releases from main > >> line > >>>>>> frequently and regularly. Hopefully 1.19 will arrive soon enough for > >> your > >>>>>> purposes. > >>>>>> > >>>>>> Julian > >>>>>> > >>>>>> > >>>>>>> On Feb 12, 2019, at 5:27 AM, Stamatis Zampetakis < > zabe...@gmail.com> > >>>>>> wrote: > >>>>>>> > >>>>>>> In order to enable Calcite on a downstream project I need to patch > >>>>>>> the official release with the PRs of the fo
Re: "ASF GitHub Bot added a worklog" emails
Julian - It might be because you are the default assignee for tickets? I know I'm assigned tickets or watching them in other projects I get more notifications. Kevin Risden On Fri, Feb 22, 2019 at 4:23 AM Francis Chuang wrote: > Would it make sense to have a separate list for Github notifications? > This would be similar to the commits@ list but would be dedicated to > archiving those Github notifications. > > On 22/02/2019 6:44 pm, Vladimir Sitnikov wrote: > > Julian>I’m getting a dozen or so such emails each day. It seems that > > one bot is adding a work log > > > > I do get those though I have just a few of them somehow. > > > > Francis> I do get a lot of emails via the list for Github comments, > reviews and > > Francis> PRs and I am somewhat questioning the utility of those emails. > > > > The thing is GitHub is not searchable. Even if you remember a comment, > > you can't really find it via Google or whatever. > > So archiving GitHub comments to at least a single mailing list makes > sense. > > > > Vladimir > > > >
Re: Calcite-Master - Build # 1027 - Still Failing
https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix That page has details about Jenkins INFRA structure stuff. Kevin Risden On Fri, Feb 22, 2019 at 9:14 AM Stamatis Zampetakis wrote: > BTW, which version of jdk1.8 we are using on Jenkins? It says latest but I > cannot find to which version latest really corresponds. > Is it this one jdk-8u201-linux-x64? > > Στις Παρ, 22 Φεβ 2019 στις 1:59 μ.μ., ο/η Stamatis Zampetakis < > zabe...@gmail.com> έγραψε: > > > Yes, I' ve noticed :( Let's keep looking! > > > > Στις Πέμ, 21 Φεβ 2019 στις 12:48 μ.μ., ο/η Vladimir Sitnikov < > > sitnikov.vladi...@gmail.com> έγραψε: > > > >> I've performed multiple builds, and it looks like Java8 is still > suffering > >> from misunderoptimization :( > >> https://builds.apache.org/job/Calcite-Master/1029/ > >> https://builds.apache.org/job/Calcite-Master/1031/ > >> > >> Vladimir > >> > > >
Re: [DISCUSS] Towards Calcite 1.19.0
It looks like there are some PRs to be reviewed and some changes to get merged in this week. How does creating the first RC on Monday Feb 25th sound? Does that give enough time this week to get changes into Calcite 1.19.0? Kevin Risden On Wed, Feb 13, 2019 at 11:08 AM Zoltan Haindrich wrote: > > On 2/13/19 4:24 PM, Julian Hyde wrote: > > Sorry, there’s been a misunderstanding. Let me clarify. I didn’t say > that your patches were too small. Or intend to imply it. > > > > When I said “widespread changes for no good reason” - or something like > that - I meant changes to the RexNode format due to removing IS TRUE nodes. > > > > I like small patches, provided each one fixes a well defined issue and > has appropriate tests. > > From now on I will try to provide a testcase when opening the jira. > Sorry for the misunderstanding, thank you for making it clear! > > > > > Julian > > > >> On Feb 13, 2019, at 3:40 AM, Zoltan Haindrich wrote: > >> > >> Hello, > >> > >> In Hive I'm a little bit behind in upgrading to 1.18 and although the > upgrade would not cause any correctness issues; but in a sense it's more > conservative in doing some simplifications - which could be interpreted as > regressions; if we take that into account that even the plan could get > worse. > >> > >> I've a few patches almost ready - they are very small changes (actually > Julian mentioned that they are kinda too small, so next time I will not be > opening separate jiras for them) > >> > >> I will finish them and launch a custom Hive test with the latest master > to see if there are any new issues coming from that direction. > >> I should get the results for it by tomorrow. > >> > >> cheers, > >> Zoltan > >> > >> > >>> On 2/12/19 11:30 PM, Stamatis Zampetakis wrote: > >>> I was not suggesting changing the release process. I wanted just to > >>> highlight the fact that if the aforementioned tickets are not part of > 1.19 > >>> I will have to create an unofficial bundle which includes them in > order to > >>> keep the downstream project working. Sorry for the confusion. > >>> Στις Τρί, 12 Φεβ 2019 στις 8:56 μ.μ., ο/η Julian Hyde < > jh...@apache.org> > >>> έγραψε: > >>>> Stamatis, > >>>> > >>>> We’ve so far managed to avoid making patch releases. It keeps life > simpler > >>>> if all releases are from the main line. And simple is important, > given that > >>>> there are no salaried release or QA engineers working on Calcite. > >>>> > >>>> But as part of that contract, we commit to making releases from main > line > >>>> frequently and regularly. Hopefully 1.19 will arrive soon enough for > your > >>>> purposes. > >>>> > >>>> Julian > >>>> > >>>> > >>>>> On Feb 12, 2019, at 5:27 AM, Stamatis Zampetakis > >>>> wrote: > >>>>> > >>>>> In order to enable Calcite on a downstream project I need to patch > >>>>> the official release with the PRs of the following Jiras. > >>>>> > >>>>> [CALCITE-2464] Allow to set nullability for columns of structured > types > >>>> [1] > >>>>> [CALCITE-2677] Struct types with one field are not mapped correctly > to > >>>> Java > >>>>> Classes [2] > >>>>> [CALCITE-2776] Wrong value when accessing struct types with one > attribute > >>>>> [3] > >>>>> > >>>>> I think the discussion has advanced quite a lot for CALCITE-2464 so I > >>>> could > >>>>> probably take it on my self, > >>>>> but I would really appreciate some input regarding CALCITE-2677 and > >>>>> CALCITE-2776. > >>>>> Let's continue the discussion under the respective Jiras. > >>>>> > >>>>> Best, > >>>>> Stamatis > >>>>> > >>>>> [1] https://jira.apache.org/jira/browse/CALCITE-2464 > >>>>> [2] https://jira.apache.org/jira/browse/CALCITE-2677 > >>>>> [3] https://jira.apache.org/jira/browse/CALCITE-2776 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Στις Δευ, 11 Φεβ 2019 στις 9:49 μ.μ., ο/η Francis Chuang < > >>>>> fr
[DISCUSS] Towards Calcite 1.19.0
Calcite 1.18.0 was released on 2018-12 (coming up on 2 months ago). It is time to get the ball rolling for the Calcite 1.19.0 release since there have been releases every 2-3 months. Calcite currently has 32 JIRA issues tagged for 1.19.0 with 68 commits. Avatica currently has 2 JIRA issues tagged for avatica-1.14.0 with 8 commits. Are there any JIRA cases that should make it into 1.19.0 but are not yet finished? Since there are only two minor commits to Avatica I don't think we need a new Avatica release before the Calcite release. Kevin Risden
Re: Release managers
I can volunteer to do the 1.19 2019-02 release. We are getting to midway through February :) Kevin Risden On Thu, Feb 7, 2019 at 3:23 AM Julian Feinauer wrote: > Hey all, > > I don't know if this is unusual or undoable due to permission issues as > I'm no commiter. > But I'd like to offer my duties as RM. > I am not that familiar with Calcite releases but just finished my first > official release for an Apache Projekt with PLC4X. > > Best > Julian > > > Am 06.02.19, 21:00 schrieb "Julian Hyde" : > > Any volunteers for 1.19? > > We now have > > Release Target date Release manager > === === === > 1.192019-02 > 1.202019-04Michael Mior > 1.212019-06Stamatis > 1.222019-08 Andrei > 1.232019-10 > > > On Feb 4, 2019, at 10:17 AM, Michael Mior wrote: > > > > Great idea. I was intending to volunteer as RM last time, but with > the > > time pressure, I didn't respond soon enough. I'm happy to take the > > April release (1.20). > > > > -- > > Michael Mior > > mm...@apache.org > > > > Le jeu. 31 janv. 2019 à 18:54, Andrei Sereda a > écrit : > >> > >> Release Target date Release manager > >> === === === > >> 1.192019-02 > >> 1.202019-04 > >> 1.212019-06Stamatis > >> 1.222019-08 Andrei > >> 1.232019-10 > >> > >> On Thu, Jan 31, 2019 at 6:14 PM Stamatis Zampetakis < > zabe...@gmail.com> > >> wrote: > >> > >>> Release Target date Release manager > >>> === === === > >>> 1.192019-02 > >>> 1.202019-04 > >>> 1.212019-06Stamatis > >>> 1.222019-08 > >>> 1.232019-10 > >>> > >>> Στις Πέμ, 31 Ιαν 2019 στις 7:46 μ.μ., ο/η Julian Hyde < > jh...@apache.org> > >>> έγραψε: > >>> > >>>> Calcite needs to make regular releases, and we have established a > cadence > >>>> of every 2 - 3 months that everyone seems to like. But to keep > that > >>>> running, each release needs a release manager, and finding a > release > >>>> manager always seems to be a chore. > >>>> > >>>> I wonder if we have trouble recruiting release managers because > we only > >>>> ask for one at a time. How about we get volunteers for the next 5 > >>> releases? > >>>> Then everyone will be seen to be doing their fair share. > >>>> > >>>> Release Target date Release manager > >>>> === === === > >>>> 1.192019-02 > >>>> 1.202019-04 > >>>> 1.212019-06 > >>>> 1.222019-08 > >>>> 1.232019-10 > >>>> > >>>> I propose that frequent committers (anyone who had 2 or more > fixes in > >>> 1.18 > >>>> and 1 or 2 fixes in 1.16 or 1.17) should all step up and be > release > >>> manager > >>>> for one of the releases this year. > >>>> > >>>> Julian > >>>> > >>>> > >>> > > > >
Calcite Avatica - JIRA version cleanup?
I was looking at JIRA and noticed that avatica-1.13.0 was marked as unreleased and there is no avatica-1.14.0 version number. There are some issues still tagged as avatica-1.13.0 but not resolved. I don't have permissions in JIRA to add the new version or mark avatica-1.13.0 as released. https://issues.apache.org/jira/projects/CALCITE/versions/12343546 I'm not sure if this might have been missed as part of releasing Avatica 1.13.0? Maybe there isn't a release step for this? Kevin Risden
