Thank you for your comment. Based on our discussion, I renamed the new
"namespaces" field to "namespace-path". This change better reflects that
the field identifies a single namespace and differentiates it from the
namespace parameter, which is a single string.
Please continue to vote.
Thanks,
Ho
Hi Yun,
Your proposal LGTM.
However, regarding compatibility, I think this information has to be
tracked regardless of the release cycle, because users can mix different
client / server versions in their environments.
Cheers,
Dmitri.
On Tue, Mar 25, 2025 at 5:01 PM yun zou wrote:
> Hi Team,
>
Thanks for the update Honah!
Upgrading my vote to +1
Cheers,
Dmitri.
On Fri, Apr 4, 2025 at 7:54 PM Honah J. wrote:
> Thank you for your comment. Based on our discussion, I renamed the new
> "namespaces" field to "namespace-path". This change better reflects that
> the field identifies a singl
Hello!
I wanted to continue discussion that had started during review of the
initial Catalog Federation API spec (
https://github.com/apache/polaris/pull/1026) regarding how we want to
handle secrets.
I drafted this document describing how secrets management fits in to
Catalog Federation, while e
I'm OK with 0.10.0-preview or Robert's idea of with a "-beta" or
"-experimental" or 1.0.0-preview. We just need to give users a clear
message that it's not a stable release you can rely on.
Yufei
On Wed, Mar 19, 2025 at 7:25 AM Jean-Baptiste Onofré
wrote:
> Thanks guys for the feedback.
>
> @Y
Hi folks,
As already proposed on another thread, and after our Community Meeting
yesterday, I would like to propose a Community Meeting to have an
update about the recent improvements we did (and still doing :)) on
Polaris Persistence.
I sent an invite for Thursday, March 27th, 9am PST.
Here's t
For visibility: I posed my comment in GH (minor):
https://github.com/apache/polaris/pull/1284#discussion_r2022896891
Cheers,
Dmitri.
On Mon, Mar 31, 2025 at 2:55 PM Yufei Gu wrote:
> Hi folks,
>
> I'm proposing to rename the table maintenance policy "snapshot-retention"
> to "snapshot-expiry".
Having benchmark results against individual commits is a great thing to
have.
The small GH hosted runners however are not suitable for
deterministic/comparable results.
It would be possible though, if the hardware (or bare-metal compute
instances in the cloud) is available to the project. I
Hi Yufei,
Thanks for your reply!
I propose to use 0.10.0-beta (as consensus).
I'm moving forward on the PR about LICENSE/NOTICE and checking the
artifacts. I will create this milestone on GitHub.
Thanks,
Regards
JB
On Thu, Mar 20, 2025 at 8:04 PM Yufei Gu wrote:
>
> I'm OK with 0.10.0-preview
Hi folks,
I'd like to raise a vote for adding `inhertied` and `namespaces` fields to
GetApplicablePolicies' response. These fields give users more information
about whether the effective policy is inherited from its parent and the
namespaces where the effective policy is located. You can find more
Thanks for bringing this up, Jonas!
The changes make sense to me!
Yufei
On Sat, Mar 29, 2025 at 5:44 PM Honah J. wrote:
> Hi folks,
>
> I'd like to propose a change to our existing GetApplicablePolicies API
> endpoint (GET /v1/{prefix}/applicable-policies) and gather your feedback.
>
> Curren
+0 the PR looks ok to me, but I made a non-critical comment in GH.
Thanks,
Dmitri.
On Fri, Apr 4, 2025 at 5:23 PM Honah J. wrote:
> Hi folks,
>
> I'd like to raise a vote for adding `inhertied` and `namespaces` fields to
> GetApplicablePolicies' response. These fields give users more informatio
12 matches
Mail list logo
