Re: [DISCUSS] CODEOWNERS file

AFAIK, CODEOWNERS is just for notifications. Write access is configured differently. Cheers, Dmitri. On Fri, Jun 13, 2025 at 1:18 PM Yufei Gu wrote: > Agreed to remove automatic tagging. Just one minor concern, does removing > CODEOWNERS impact committers' write privilege? I hope not. > > Yufei

Re: [DISCUSS] Prepare for 1.0 Release

Dimiri, Thanks a lot for driving this initiative[1]. Can you raise a separate dev mail thread for this? I think this deserves a broad awareness. 1. https://github.com/apache/polaris/pull/1890 Yufei On Fri, Jun 13, 2025 at 4:53 AM Robert Stupp wrote: > I was thinking of how the Docker images

[DISCUSS] CODEOWNERS file

Hi, as of today, every committer to Polaris is mentioned in the CODEOWNERS file. This forces every committer to receive an email for every PR creation, every comment, every merge and so on - quite a lot of emails every day. IMHO it's already quite difficult to prioritize those or even figure

Re: [DISCUSS] CODEOWNERS file

I agree that the automatic tagging is getting out of hand, thanks for raising this. I think just deleting CODEOWNERS is a pretty good idea. Once that's done however, I worry that a potential contributor might not know who to tag on a PR and might either just pick someone randomly or be stuck waiti

Adding Support for Apache Hudi within Polaris

Hi all, I would like to start a discussion about adding support for Apache Hudi tables within Apache Polaris. I was able to look into the recent integration that was done for adding Delta as a Generic Table within Polaris , and b

Re: [DISCUSS] Prepare for 1.0 Release

Hi Robert, hi all, I do agree with you that we need to distinguish between nightlies and production-ready artifacts, mainly because these repositories will be fed by fairly diverse pipelines: nightly images will be provided by an automated pipeline with no guarantee whatsoever about the contents i

Re: [DISCUSS] Prepare for 1.0 Release

Hi Dmitri, We don't have a consensus on adding these two PRs as 1.0 blocker. Can you please drop the label? Let's discuss it first. I don't think they are 1.0 blockers, but open to suggestions. 1. https://github.com/apache/polaris/pull/1889 2. https://github.com/apache/polaris/pull/1890 Yufei

Re: [DISCUSS] CODEOWNERS file

Agreed to remove automatic tagging. Just one minor concern, does removing CODEOWNERS impact committers' write privilege? I hope not. Yufei On Fri, Jun 13, 2025 at 9:48 AM Eric Maynard wrote: > I agree that the automatic tagging is getting out of hand, thanks for > raising this. I think just de

[Polaris Community Sync] June 12, 2025

Hi folks, Thanks to everyone who participated in the Polaris community meeting yesterday. Here's the record: https://drive.google.com/file/d/1QjMpC87ML6kH4EC2Ni5j29W71yBsHigo/view?usp=sharing I will create the PR to update the website. Thanks ! Regards JB

Re: [DISCUSS] Prepare for 1.0 Release

Hi Yufei, I agree that we do not have consensus on the _contents_ of PRs 1889 and 1890. However, I believe the issues these PRs attempt to address are still 1.0 blockers in my opinion (arguments for that given in previous emails). I'd say removing the blocker label from them itself needs consens

Re: Adding Support for Apache Hudi within Polaris

Hey Laurent, For general concerns about generic tables, it may be best to revisit some of the threads about that design. There’s a proposal doc from February that discusses some of the questions you raise here. I’m not sure if it makes sense to relitigate the generic tables design every time an ex

Re: [DISCUSS] Polaris Evolution statements for 1.0

Hi All, I made a few edits to the PR with feedback in mind, but not always strictly following suggestions. Please review again and comment if you disagree with my edits. Note: I added a new section for "Managing Polaris Database". I meant to have it in this PR right away, but simply forgot to wr

Re: Adding Support for Apache Hudi within Polaris

Thanks for the proposal. +1 on adding Hudi support. Since Hudi doesn’t currently have an IRC (Iceberg REST Catalog)-like specification, the proposed approach looks reasonable. Yufei On Fri, Jun 13, 2025 at 8:41 AM Rahil C wrote: > Hi all, > > I would like to start a discussion about adding sup

Re: [DISCUSS] Prepare for 1.0 Release

FYI, we fixed a few script and doc issues this week for the branch release/1.0.x! Special thanks to Eric, Yun, William, Jonas and Prashant for going through each individual doc and script, testing them out, filing issues and fixing. You can find the whole list here, https://github.com/apache/polari

Re: Adding Support for Apache Hudi within Polaris

Same comment as in the other thread regarding location and generic table: how are clients supposed to interact with this format? Could we have a detailed discussion about the protocol between the catalog and the query engine? Laurent On Fri, Jun 13, 2025, 17:01 Vinoth Chandar wrote: > +1 > > I

Re: [DISCUSS] Prepare for 1.0 Release

I'm OK with the consensus process. Can you explain why introducing a blocker doesn't need consensus? This is to have a community-wide acknowledgement whether the _issues_ represented by those PRs are not critical for 1.0. My opinion is that the issues are critical, even though we do not have an

[DISCUSS] Polaris Evolution statements for 1.0

Hi All, As discussed in the community sync yesterday, I raised PR [1890] to inform users about what to expect as Polaris evolves. Please review and comment in the PR. If you have a bigger concern, it might be best to reply to this thread instead. I will send a separate email notice if / when the

Re: [DISCUSS] Prepare for 1.0 Release

Hi Yufei, Certainly, here's the dedicated discussion thread for PR 1890: https://lists.apache.org/thread/c0sk6hmtz9l4vs0mjc21wvlpblqhgx7r Cheers, Dmitri. On Fri, Jun 13, 2025 at 12:52 PM Yufei Gu wrote: > Dimiri, > > Thanks a lot for driving this initiative[1]. Can you raise a separate dev >

Re: [DISCUSS] Prepare for 1.0 Release

Thanks for raising this, but I disagree on three fronts: - Neither 1889[1] nor 1890[2] introduces a functional gap that would prevent users from adopting 1.0. They document best-practice guidance we can safely refine post-GA. Holding the release hostage to docs or policy wording sets a

Re: [DISCUSS] CODEOWNERS file

Hi I agree to remove the file. It doesn’t have any impact on committee privileges (that’s manage on whimsy). Regards JB Le ven. 13 juin 2025 à 19:17, Yufei Gu a écrit : > Agreed to remove automatic tagging. Just one minor concern, does removing > CODEOWNERS impact committers' write privilege?

Re: Adding Support for Apache Hudi within Polaris

Hi Rahil, Thanks a lot for working on this! This is definitely one valuable feature improvement for the Spark Client support, I am really looking forward to that! The overall approach looks good to me! Best Regards, Yun On Fri, Jun 13, 2025 at 3:47 PM Yufei Gu wrote: > Thanks for the proposal

Polaris Community Sync on Events

Hi all, As we were not able to discuss at the previous community sync, I’m setting a quick sync early next week to discuss Events in Persistence (PR: https://github.com/apache/polaris/pull/1844). Everyone is welcome to join and discuss on next steps here. Thanks! Best, ADNAN HEMANI Polaris Co

Invitation: Polaris Community Sync on Events @ Tue Jun 17, 2025 9am - 10am (PDT) (dev@polaris.apache.org)

BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/Los_Angeles X-LIC-LOCATION:America/Los_Angeles BEGIN:DAYLIGHT TZOFFSETFROM:-0800 TZOFFSETTO:-0700 TZNAME:PDT DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH

Updated invitation: Polaris Community Sync on Events @ Tue Jun 17, 2025 9am - 9:30am (PDT) (dev@polaris.apache.org)

BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/Los_Angeles X-LIC-LOCATION:America/Los_Angeles BEGIN:DAYLIGHT TZOFFSETFROM:-0800 TZOFFSETTO:-0700 TZNAME:PDT DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH

Re: Adding Support for Apache Hudi within Polaris

+1 I am on the Hudi PMC. This will nicely augment our HMS++ metastore and Apache Gravitino support. Bring a lot of benefits to both Hudi and Polaris communities. On 2025/06/13 22:54:43 yun zou wrote: > Hi Rahil, > > Thanks a lot for working on this! This is definitely one valuable feature >

Re: Adding Support for Apache Hudi within Polaris

Hi Rahil It's interesting, thanks for that. As a first step, the approach corresponds to the one used for Delta. Long term, I would love to see support on other table formats directly in the catalog (without the need of a fat client, I already mentioned that while ago). So , +1 for now, but I st

Re: [DISCUSS] Prepare for 1.0 Release

I agree that doing the renaming now (before the 1.0 release) is much much easier even if it'd be renamed in a following major release. I hear there are concerns about the current naming. The current name was chosen at that time to disambiguate the "Quarkus variant" from the previous one, which

Re: [DISCUSS] Prepare for 1.0 Release

+1 on "1.0-blocker" for both 1889 + 1890 On 13.06.25 04:24, Dmitri Bourlatchkov wrote: As discussed in the community sync today, I opened PR [1890] to inform users about what to expect in terms of backward compatibility as the project evolves. I proactively marked it as 1.0 blocker because I'm

Re: [DISCUSS] Prepare for 1.0 Release

Thanks for raising these questions! These are all thoughts that have quite an impact on several aspects: * Will there be 1.0.x releases? * If so, how long will 1.0.x be maintained? * Will 1.1 be based on 1.0 or main? * What if we put 2.x into the mix? There are even more "questions" to that - t

Re: [DISCUSS] Prepare for 1.0 Release

I was thinking of how the Docker images are being staged and eventually released. I know there was a dev-ML thread about this, but I think this topic is important for the 1.0 release, so raising it here. The release-guide doesn't mention images at all, so the process isn't clear. TL;DR of my r

Re: [DISCUSS] Branches in the github repository / + stale branches

Deleting the release/0.9+10 branches is fine for me. Any objections to delete those? On 13.06.25 03:35, Michael Collado wrote: I have no objections. Any of my old branches are there purely accidentally. Mike On Thu, Jun 12, 2025 at 1:48 PM Yufei Gu wrote: +1, I'm all for keeping the code

Re: [DISCUSS] Branches in the github repository / + stale branches

Hi I agree to delete release/0.10 branch (as it's not used anymore). However, I would keep release/0.9 for now as we did a release on this branch, so we could have a request from the community to do a new release (0.9.1, etc), even if I don't think it will happen :) Regards JB On Fri, Jun 13, 2

Re: [DISCUSS] CODEOWNERS file

I'm fine with removing CODEOWNERS completely. However, AFAIK CODEOWNERS allows selective attribution by regex or something like that. How about we keep CODEOWNERS but link committers to code areas voluntarily? I mean each committer could personally make a PR against CODEOWNERS to get notified on