I just filed https://github.com/apache/polaris/issues/540 to track this
feature request, and wrote up this document to try to better solidify our
terminology and concepts on related federation features, while also
sketching out a proposal for a basic MVP of catalog federation that could
be easily e
This sounds great to me. Thanks, Yufei!
Mike
> On Dec 11, 2024, at 5:03 PM, Yufei Gu wrote:
>
> Hi Folks,
>
> Thanks a lot for all the feedback. The majority seems to favor Slack.
> Some prefer Zulip. I feel like it’s worth giving Slack a try as an
> alternative to Zulip. If everything works
I agree. And I especially agree with the point regarding features over
technical discussions.
I feel like there’s been a bit of bike-shedding (I can bike-shed with the best
of them, I’m afraid) on details that are somewhat inconsequential. Things like
support for specific NoSQL database (mongo
Hi Folks,
Thanks a lot for all the feedback. The majority seems to favor Slack.
Some prefer Zulip. I feel like it’s worth giving Slack a try as an
alternative to Zulip. If everything works well, we can continue with Slack,
and even promote it to be the only one in the future. If it turns out not
w
I'm strongly in favor of moving ahead with the work on the persistence
layer and improving the plugin experience/ integration
with Quarkus. I think we've really highlighted the importance lately of
improving the first time user experience with the product
and the ability to run Polaris in isolatio
Hi folks,
It would be useful to add a generic event listener interface to Polaris,
consistent with other OSS projects. Users of the project may require
additional functionality that doesn't have a clear enough value proposition
to be in OSS. Instead, there can be event listeners that let you hook
