Thanks Stamatis! I appreciate all the work you've done. Just a note
for future reference so that I don't forget to mention later: the logo
should be committed to the comdev repo when finalized (see link
below).
https://www.apache.org/logos/about.html
--
Michael Mior
mm...@apache.org
Le mer. 3 jui
The Apache Jenkins build system has built Calcite-Master (build #1235)
Status: Still Failing
Check console output at https://builds.apache.org/job/Calcite-Master/1235/ to
view the results.
godfrey he created CALCITE-3169:
---
Summary: decorrelateRel method should return when meeting
SEMI/ANTI join in RelDecorrelator
Key: CALCITE-3169
URL: https://issues.apache.org/jira/browse/CALCITE-3169
Pr
Danny Chan created CALCITE-3168:
---
Summary: Add test for invalid literal of sql parser
Key: CALCITE-3168
URL: https://issues.apache.org/jira/browse/CALCITE-3168
Project: Calcite
Issue Type: Sub-
Good point Vladimir. Given that Java 9 reached already the end of its life
I think we should remove it from our CI.
Other than that I am curious to understand why the problem appeared now to
better prevent such situations in the future.
On Tue, Jul 2, 2019 at 3:22 PM Vladimir Sitnikov <
sitnikov.
Thanks Michael!
The logo 5H [1] is basically 2B with the font of 2C. I will prepare a PR
and we can move the discussion there.
[1]
https://github.com/zabetak/calcite/blob/calcite-logo/site/img/index.md#candidate-5h
On Tue, Jul 2, 2019 at 10:38 PM Michael Mior wrote:
> Sounds good to me. I'm
Dear Members of Calcite Community,
I'm working on Apache Beam SQL and we use Calcite for query optimization.
We represent both tables and streams as a subclass of
AbstractQueryableTable. In calcite implementation of cost model and
statistics, one of the key elements is row count. Also all the node
Sounds good to me. I'm away at a conference this week so I have
minimal bandwidth, but I'll try to get to it as soon as possible when
I get back.
--
Michael Mior
mm...@apache.org
Le mar. 2 juil. 2019 à 21:06, Julian Hyde a écrit :
>
> Now we’ve had a vote to establish broad direction, I think you
Sorry this was for dev@jmeter.
Vladimir
I wonder if we should implement a check for "underoptimized pngs" in the
PRs.
png volume towards JMeter download size which is not that good.
Vladimir
Julian>Do you propose to remove pom.xml files from git
Of course I do.
I just thought "migrate Maven to Gradle" to mean "we fully replace Maven
with Gradle",
not like "we add Gradle build scripts and support two build systems at the
same time".
Julian>generate them upon release
Gradle can genera
Julian>People reviewing the release can run those same reports
Julian>Those reports don’t necessarily need to be published.
Publishing the reports would simplify the review.
Of course people might ignore those reports, however the availability of
the reports does help with the review.
Vladimir
I will support changes, such as you describe, that add a language and remove
another.
I am wary of changes that add a new language (or framework, for that matter) to
the mix. Hence my pushback against your use of .kts files.
We can’t entirely remove Maven and pom.xml files from the process. pom
The web site process is not broken.
There are some minor licensing bugs. Let’s fix them. Let’s talk about how we
can improve the process. The existence of bugs doesn’t mean the process is
broken.
The release manager must review the licensing/security reports. People
reviewing the release can r
Michael>One of the concerns was adding another language
It is not adding, but it is replacing a language.
I replace "pom logic written in XML" with "Gradle logic written in Kotlin".
Then it would probably replace /bin/bash-driven logic with the same
"Gradle+Kotlin",
which would remove yet another
Julian>And if it ain’t broke, don’t fix it.
It is broken. Both Avatica and Calcite releases violate ASF licensing
policy (at least as per https://www.apache.org/legal/resolved.html definition
of that)
Julian>This change would be adding another thing for people voting on
releases to review
Do you
Now we’ve had a vote to establish broad direction, I think you (Michael) should
tweak the logo as you see fit, and you don’t need to ask permission from the
dev list for those changes. I think the regular PR process will suffice.
Thank you for driving this.
> On Jul 1, 2019, at 9:54 PM, Michael
When I said “is there a significant problem” I meant an existing problem. I
don’t think there is an existing problem. And if it ain’t broke, don’t fix it.
This change would be adding another thing for people voting on releases to
review. I don’t want to add that burden.
Julian
> On Jul 2, 201
The Apache Jenkins build system has built Calcite-Master (build #1234)
Status: Still Failing
Check console output at https://builds.apache.org/job/Calcite-Master/1234/ to
view the results.
Michael>We regularly force push to the Calcite repo, so this is not a
Michael>restriction we face.
I suggest we just continue with that (fix small typos via amend/rebase)
Michael>The two repos are already separate so I don't think this is a big
Michael>departure
How are you going to check(test)
> As you say, you "haven't encountered that".
My maven does work the same as yours in that I do have to take the
steps you outlined. I just haven't found it to be burdensome.
> I know of no Java-based build system. Why do you ask for that?
One of the concerns was adding another language. If this
Let me paraphrase.
You asked for proof. No proof is needed. It is self-evident.
Julian
> On Jul 2, 2019, at 9:01 AM, Vladimir Sitnikov
> wrote:
>
> Michael> I agree with Julian's point about adding maintenance
> Michael> overhead.
>
> Frankly speaking, it is (still) extremely hard for me t
Sigh. More process, more technology. At a time when our release managers are
more burdened than ever.
Is there a significant problem where we publish a release and the site is
screwed up?
If so, let’s roll back the change to go to GitHub pages. When we generated the
site locally using Jekyll t
Comments inline.
Le mar. 2 juil. 2019 à 16:17, Vladimir Sitnikov
a écrit :
>
> Micael>How so? Just delete the branch or rebase to delete the commits. I
> fail
> to see the complexity here.
>
> The complexity is not technical. It is INFRA who prohibits rebases.
> That is why I suggest we don't put
> Gradle makes that possible with virtually zero configuration.
Can't agree more. In the long term, Gradle has lower maitainence cost than
Maven (look at the gradle scripts and Maven pom file), let alone the
performance improvement.
- Haisheng
---
Michael> I agree with Julian's point about adding maintenance
Michael> overhead.
Frankly speaking, it is (still) extremely hard for me to decipher Julian's
mail.
It is so dense that I can't really understand the meaning.
For instance:
Julian>Proof that the amount of knowledge required to maintai
Micael>How so? Just delete the branch or rebase to delete the commits. I
fail
to see the complexity here.
The complexity is not technical. It is INFRA who prohibits rebases.
That is why I suggest we don't put "build artifacts" into the main source
repositories.
In the worst case we just throw away
1) Michael, Julian, Danny, et all. Thanks for the participation.
2) There's a separate thread for Gradle discussion. Please find it by the
subject of "CALCITE-3158, Avatica: migrate build system to Gradle".
3) I would really like to keep this thread dedicated to "LICENSE file
formatting".
Of cour
I haven't really encountered the same problems with Maven that you
have and I agree with Julian's point about adding maintenance
overhead. However, the build time improvements are impressive. Is
there any reason we need to use Kotlin for the build script? Couldn't
this just be more Java?
--
Michael
>1) I guess we'd better have a single repository for both Avatica and Calcite
Why do we need both to be in the same repository if we're just using
it for testing?
>2) Pushing site/reports to Git repository (e.g. apache/calcite.git) would
>count towards repository size , thus it would impact every
The Apache Jenkins build system has built Calcite-Master (build #1233)
Status: Still Failing
Check console output at https://builds.apache.org/job/Calcite-Master/1233/ to
view the results.
Dear all,
I was wondering if someone could tell me whether I am using the
materialization service to define a materialized view correctly.
The materializationService.defineMaterialization[1] takes a few arguments,
the one I might be confused about is the viewSql argument. Right now I have
the mat
Just a side note: do we really need/want to support Java 9?
What if we just skip Java9 and stick with Java 8, 11, and later EAP
eversions?
Does anybody really uses Java 9 in production?
What's the purpose of supporting that?
Frankly speaking, "Java 9" related failures are a pure noise to me.
The
FYI: I created [1], if it is not an INFRA problem I will try to have a look
at it.
Best,
Stamatis
[1] https://issues.apache.org/jira/browse/INFRA-18694
On Mon, Jul 1, 2019 at 1:34 PM Stamatis Zampetakis
wrote:
> It looks like an INFRA problem. Should we report this?
>
> On Sun, Jun 30, 2019 at
The Apache Jenkins build system has built Calcite-Master (build #1232)
Status: Still Failing
Check console output at https://builds.apache.org/job/Calcite-Master/1232/ to
view the results.
jin xing created CALCITE-3167:
-
Summary: Remove redundant overriding methods of equals&hashcode in
EnumerableTableScan.java
Key: CALCITE-3167
URL: https://issues.apache.org/jira/browse/CALCITE-3167
Projec
36 matches
Mail list logo
