-1 (binding)
Overall reasons for the -1:
* zip/tarball/images missing
* license/notice issues
* broken(?)/different commit content
Zip and tarball binaries for `polaris-server` and `polaris-admin` are
missing in the Maven publication.
Docker images for `polaris-server` and `polaris-admin` ar
+1, verified spark client package use case.
On Mon, Jun 23, 2025 at 6:24 PM Yufei Gu wrote:
> Hi everyone,
>
> I propose that we release the following RC as the official
> Apache Polaris 1.0.0-incubating release.
>
> This corresponds to the tag: apache-polaris-1.0.0-incubating-rc0
> *
>
> https:
+1 on the 1.0 release.
I have verified manually with the spark client package use case with the
current maven repo, I was able to create/insert/drop iceberg and delta
table as expected.
Best Regards,
Yun
On Mon, Jun 23, 2025 at 6:32 PM Yufei Gu wrote:
> Thanks a lot for everyone working on thi
Thanks a lot for everyone working on this! Sent out the 1.0.0 RC0 release
vote mail!
Yufei
On Mon, Jun 23, 2025 at 6:27 AM Dmitri Bourlatchkov
wrote:
> Re: 1: We have PR [1908], but no issue AFAIK.
>
> [1908] https://github.com/apache/polaris/pull/1908
>
> Cheers,
> Dmitri.
>
> On Mon, Jun 23,
Hi everyone,
I propose that we release the following RC as the official
Apache Polaris 1.0.0-incubating release.
This corresponds to the tag: apache-polaris-1.0.0-incubating-rc0
*
https://github.com/apache/polaris/commits/apache-polaris-1.0.0-incubating-rc0
*
https://github.com/apache/polaris/tre
Apologies for missing the reference to Robert's doc. I hope it does not
invalidate my comments :)
This is certainly up for discussion.
To clarify my concern about the REST API: If we are to have resilient tasks
and the node that serves the initial REST request fails, other nodes will
have to be a
Thanks for these concrete concerns. The way I see it is that the
file-buffer implementation is again, a customer-choice they can make. If
they are using ephemeral storage or more complicated persistent volumes,
they still have the ability to write their own event
listener implementation and use tha
Hey Dmitri,
There's a section in the email above and the linked doc that talks about
the linked proposal. See "Relationship to the "Asynchronous & Reliable
Tasks" Proposal".
As for pulling away from a REST API in favor of driving things directly
from persistence, there's a lot to discuss here. Be
Hi All,
A previous proposal by Robert [1] from May 9 appears to be related. I think
we should consider both at the same time, possibly as alternatives, but
perhaps also sharing / reusing their respective ideas.
A few notes after a quick review:
* Separate scaling for task executors seems reasona
>
> I'm not sure the pros and cons about these two concerns were discussed.
> Those are general decisions that IMO require a bigger audience than a
> single code-level comment in one PR.
I understand where you're coming from. To keep things moving, I'm proposing
a one-week time limit on this disc
Hello Polaris Community,
I would like to share my proposal for a new service, the Polaris
Delegation Service, and to share the design document for discussion
and feedback. The Delegation Service is intended to optionally be
deployed alongside Polaris to handle the execution of certain
long-running
Re: 1: We have PR [1908], but no issue AFAIK.
[1908] https://github.com/apache/polaris/pull/1908
Cheers,
Dmitri.
On Mon, Jun 23, 2025 at 9:12 AM Jean-Baptiste Onofré
wrote:
> Hi Robert
>
> Yes, 1 has to be sorted out before the release. Do we have an issue
> about that (beyond the thread discu
Hi Yun,
I'm thinking about this approach:
* We compile against unallocated jars.
* We relocate Jackson the same way as Iceberg in our build.
* We publish the relocated Spark Client jar (thin), without any bundled
classes.
* The relocated Spark Client jar depends on Iceberg Spark runtime.
* The re
Hi Robert
Yes, 1 has to be sorted out before the release. Do we have an issue
about that (beyond the thread discussion) ? I already mentioned my
"concern" about the shadow jar in Spark client. It's important but it
can be improved later. The Maven coordinates are more problematic (if
we change lat
Not "labeled" as blockers, but two things to clarify:
1. The "[DISCUSS[ Spark Client jars: maven coordinates and shading" thread
2. Having the docs for a release appear in a URL containing "in-dev"
doesn't feel right.
The first one might have implications to the release?
On 23.06.25 13:30,
Hi folks,
I don't see any Issue or PR with the 1.0-blocker label.
I guess we are ready to cut 1.0.0 right ?
Regards
JB
On Fri, Jun 20, 2025 at 8:12 PM Yufei Gu wrote:
>
> +1 on documenting on the site, which I don't think it's a 1.0 blocker. It's
> been added into the release notes[1].
>
> [1]
I'm not sure the pros and cons about these two concerns were discussed.
Those are general decisions that IMO require a bigger audience than a
single code-level comment in one PR.
I do also prefer delegation over adding "all concerns to a single
class". It simplifies testing and separates conce
No need to apologize, but I think there are some quite important aspects
that have to be considered. Going into every explicit and implicit
detail is way too much for a single email, as it requires explaining
operating system and file system behaviors.
Since you asked for the "nitty gritty det
18 matches
Mail list logo
