I completely agree with Julian. The problem cannot be solved unless we
start investing more time in the project in the ways he already described.
What I outlined previously is an attempt to mitigate the current situation,
not something that can solve the problem for good. Nevertheless, to push
+1 to Stamatis’ idea. It won’t make things worse. :)
But to repeat what I said earlier. We need existing committers to pull their
weight. If necessary, committers need to talk to their managers and get time
allocated to contribute to “housekeeping”.
One important kind of housekeeping is
+1 on Stamatis' idea, I think it could help with the current situation of
lack of reviewers.
Best,
Ruben
On Thu, Jun 23, 2022 at 12:56 PM Charles Givre wrote:
> Hello all,
> FWIW, If a committer/reviewer shortage is the issue, I'd second Stamatis's
> recommendation.
> Best,
> -- C
>
> > On
Hello all,
FWIW, If a committer/reviewer shortage is the issue, I'd second Stamatis's
recommendation.
Best,
-- C
> On Jun 23, 2022, at 7:02 AM, Stamatis Zampetakis wrote:
>
> Hi all,
>
> How about granting Calcite committership to people who are already ASF
> committers (in other projects)
Hi all,
How about granting Calcite committership to people who are already ASF
committers (in other projects) and they have a proven record of working
with Calcite?
Usually the PMC invites people to become committers to the project after
having a few successful code contributions in
Hi everyone,
This is an awesome discussion to improve collaborating between different
projects.
Thanks Julian, Jacques, Austin, Martijn, Timo's effort to make it happen.
Best,
Jing Zhang
Martijn Visser 于2022年6月23日周四 01:43写道：
> Hi Jacques, Julian, Austin and everyone else,
>
> Thank you very
Hi Jacques, Julian, Austin and everyone else,
Thank you very much for sharing all your experiences and providing really
valuable input. I'll definitely relay this back to the original discussion
thread in the Flink community. Part of bringing this information back to
the Flink community is also
Hi everyone,
This is a really great discussion. Thanks for starting it Martijn and
your input Jacques! I have been fighting against forking Calcite in
Flink for years already. Even when merging forks of Flink that
transitively forked Calcite, in the end we were able to resolve
conflicts /
As the PMC for Apache Drill, I'd echo everyone's comments here Don't fork.
Don't do it.
Apache Drill forked Calcite several years ago which Calcite was on version 1.20
or 1.21. While this meant that some bugs were easily fixed, what it also meant
that as our fork diverged from "regular"
Martijn:
I'd interpret Julian's response as welcoming you to contribute to the
Calcite :-)
Sounds like there is concretely room for:
* reviewing ( ex: test, comment in PR, but not actually merge -- might make
it easier/quicker for the current committers to then allow them to address
other/more
Please don’t fork Calcite.
Calcite suffers from the tragedy of the commons. Unlike many open source data
projects, there is no commercial project that directly maps to Calcite (even
though Calcite is an essential part of many projects). As a result no engineers
work full-time on Calcite.
It
Martijn, thanks for sharing that thread in the Flink community.
I'm someone who has forked Calcite twice: once in Apache Drill and again in
Dremio. In both cases, it was all about trading short term benefits against
long term costs. In both cases, I think the net amount of work was probably
5x as
Thanks Julian and Austin!
Any reply to kick-off some sort of discussion is worthwhile :D
I definitely know the feeling of having more PRs open then you would like,
looking at https://github.com/apache/flink/pulls :)
There have been discussions in the Flink community about forking Calcite
[1]. My
>From the peanut gallery :-) -->
Wow; yes, lots of open PRs. https://github.com/apache/calcite/pulls
How can individuals from the Flink [sub-]community, and/or more general
calcite community help lighten this load? Is there much weight given to
reviews from non-committers; how to increase the
Martijn,
Since you requested a reply, I am replying. To answer your question, I don’t
know of a way to move this topic forward. We have more PRs than people to
review them.
Julian
> On Jun 19, 2022, at 11:58 PM, Martijn Visser wrote:
>
> Hi everyone,
>
> I just wanted to reach out to the
Hi everyone,
I just wanted to reach out to the Calcite community once more on this topic
since no reply was received. Would be great if someone could get back to us.
Best regards,
Martijn
Op wo 8 jun. 2022 om 11:24 schreef Martijn Visser :
> Hi everyone,
>
> I would like to follow-up on this
Hi everyone,
I would like to follow-up on this email that was sent by Jing. So far, no
progress has been made, despite reaching out to the mailing list, the original
Jira ticket and reaching out to people directly. Is there a way that we can
move this PR/topic forward?
For context, in Apache
Hi community,
My apologies for interrupting.
Anyone could help to review the pr
https://github.com/apache/calcite/pull/2606?
Thanks a lot.
CALCITE-4865 is the first sub-task of CALCITE-4864. This Jira aims to
extend existing Table function in order to support Polymorphic Table
Function which is
Hi community,
Please help review the pr https://github.com/apache/calcite/pull/2606,
thanks a lot.
CALCITE-4865 is the first sub-task of CALCITE-4864. This Jira aims to
extend existing Table function in order to support Polymorphic Table
Function which is introduced as the part of ANSI SQL 2016.
Hi community,
Currently, there is a minor inconsistent behavior in `RexBuilder#makeIn`.
It does not take
`RelDataTypeSystem.shouldConvertRaggedUnionTypesToVarying()` into
consideration.
I guess it's reasonable if `shouldConvertRaggedUnionTypesToVarying` is
true, we should use less restrictive
Hi community,
CALCITE-4865 is first subtask of CALCITE-4864. This Jira aims to extend
existed Table function in order to support Polymorphic Table Function which
is introduced as the part of ANSI SQL 2016.
Please help review the pr, it would be very appreciated. Thanks a lot.
The brief change
Hi team,
This PR is about supporting sorting aggregation results in Elasticsearch
Adapter, please help review it in your free time. Thanks a lot!
What’s more, the git workflow shows “First-time contributors need a maintainer
to approve running workflows”, awaiting approval?
I would take it, hole to help you.
Best,
Danny Chan
在 2019年3月13日 +0800 PM10:52，Muhammad Gelbana ，写道：
> Could someone kindly review this PR please ?
> https://github.com/apache/calcite/pull/1066
>
> Thanks,
> Gelbana
Could someone kindly review this PR please ?
https://github.com/apache/calcite/pull/1066
Thanks,
Gelbana
24 matches
Mail list logo
