Re: [ANNOUNCE] Welcome Dmitri Bourlatchkov, Dennis Huo and Yufei Gu to the Apache Polaris PPMC

[Dmitri Bourlatchkov]

Thanks all for the warm welcome :)

Cheers,
Dmitri.

On Wed, Mar 26, 2025 at 5:47 PM Russell Spitzer 
wrote:

> Hi y'all!
>
> I'm excited to let the Polaris Community know that the PPMC has added three
> new members.  Dmitri Bourlatchkov, Dennis Huo and Yufei Gu are all now
> members of the Polaris PPMC.
>
> Please join me in welcoming them,
> Russ
>

Re: [PROPOSAL] Improve our "collaboration schema"

[Jean-Baptiste Onofré]

By the way, I got some questions from some contributors.

"If I approve a PR, and the author is pushing new changes, should I
re-approve the PR ?"

The answer is no, your previous approval is still there. For instance,
on this PR https://github.com/apache/polaris/pull/1259, Eric approved,
after that I pushed a new change, Eric's approval is still there.

Optionally, we can choose to dismiss stale pull request approvals when
commits are pushed that affect the diff in the pull request. GitHub
records the state of the diff at the point when a pull request is
approved. This state represents the set of changes that the reviewer
approved. If the diff changes from this state (for example, because a
contributor pushes new changes to the pull request branch or clicks
Update branch, or because a related pull request is merged into the
target branch), the approving review is dismissed as stale, and the
pull request cannot be merged until someone approves the work again.

If we want to "force" re-approval on change, we should use
dismiss_stale_reviews: true in .asf.yaml.

See 
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging
for details.

I can change the repo configuration if needed.

Regards
JB

On Thu, Mar 27, 2025 at 8:28 AM Eric Maynard  wrote:
>
> Sounds good to me!
>
> On Wed, Mar 26, 2025 at 11:42 PM Jean-Baptiste Onofré 
> wrote:
>
> > Hi Eric
> >
> > I agree. I propose:
> >
> > 1. To update the contributor good practices on the website to clearly state
> > the keywords nit and minor.
> > 2. For request change, we can use it. For the record, we can bypass request
> > change flag if a given number of reviewers approve the PR anyway.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> > Le mar. 25 mars 2025 à 19:54, Eric Maynard  a
> > écrit :
> >
> > > In this case I think rather than a mistake, there could simply be some
> > > ambiguity around what comments are considered blocking. For example, I'm
> > > not sure if a comment prefixed "minor" should be considered blocking -- I
> > > would say probably not, but someone else could interpret it differently.
> > >
> > > To that end, I think putting these things in the guidelines could be wise
> > > even if there's not a strict enforcement of the guidelines as such. I
> > agree
> > > that it's hard to "codify a spirit", but it could be useful to have
> > > explicit expectations and guidelines written down somewhere. It could be
> > as
> > > simple as asking reviewers to "Request Changes" if they want to block a
> > PR,
> > > or advising authors to wait a couple of days before merging a PR they
> > view
> > > as complex.
> > >
> > > --EM
> > >
> > > On Mon, Mar 24, 2025 at 11:13 AM Yufei Gu  wrote:
> > >
> > > > I'm particularly concerned about what happened in PR #1230(
> > > > https://github.com/apache/polaris/pull/1230). The PR was merged
> > despite
> > > > multiple unresolved comments from a committer.
> > > >
> > > > To maintain a healthy review process, we’d like to encourage PR authors
> > > to
> > > > address open comments and work toward consensus. If necessary, relying
> > on
> > > > lazy consensus is fine.
> > > >
> > > > Let’s all try to be mindful of this going forward to ensure smooth
> > > > collaboration.
> > > >
> > > > Yufei
> > > >
> > > >
> > > > On Mon, Mar 24, 2025 at 1:55 AM Jean-Baptiste Onofré 
> > > > wrote:
> > > >
> > > > > Hi Eric,
> > > > >
> > > > > Thanks for pointing this out.
> > > > >
> > > > > I think that's unfortunate, especially for #1230 (I don't see issues
> > > > > on #1226 and #1220 as they have been approved by 3 different
> > > > > committers).
> > > > >
> > > > > I strongly believe that, as a community, we do a great work all
> > > > > together, and we highly consider comments from each other.
> > > > > If again, I think it's unfortunate for #1230, it's certainly a
> > > > > "mistake" from the author/merger and we should still give a change to
> > > > > our soft rules (before being stricter).
> > > > >
> > > > > So, I propose to continue with our soft rules and good intentions,
> > and
> > > > > if it doesn't work, then we can discuss about a stricter approach.
> > > > >
> > > > > Thoughts ?
> > > > >
> > > > > Regards
> > > > > JB
> > > > >
> > > > > On Sun, Mar 23, 2025 at 8:05 AM Eric Maynard <
> > eric.w.mayn...@gmail.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > > Revisiting this thread, I wonder if the "soft rules" are working. I
> > > > have
> > > > > > noticed quite a few PRs merged recently with outstanding comments.
> > > The
> > > > > most
> > > > > > recent of these that I personally reviewed are #1220
> > > > > > , #1226
> > > > > > , and #1230
> > > > > >  but there are
> > > doubtless
> > > > > other
> > > > > > examples.
> > > > > >

Re: [PROPOSAL] Improve our "collaboration schema"

[Eric Maynard]

Sounds good to me!

On Wed, Mar 26, 2025 at 11:42 PM Jean-Baptiste Onofré 
wrote:

> Hi Eric
>
> I agree. I propose:
>
> 1. To update the contributor good practices on the website to clearly state
> the keywords nit and minor.
> 2. For request change, we can use it. For the record, we can bypass request
> change flag if a given number of reviewers approve the PR anyway.
>
> Thoughts ?
>
> Regards
> JB
>
> Le mar. 25 mars 2025 à 19:54, Eric Maynard  a
> écrit :
>
> > In this case I think rather than a mistake, there could simply be some
> > ambiguity around what comments are considered blocking. For example, I'm
> > not sure if a comment prefixed "minor" should be considered blocking -- I
> > would say probably not, but someone else could interpret it differently.
> >
> > To that end, I think putting these things in the guidelines could be wise
> > even if there's not a strict enforcement of the guidelines as such. I
> agree
> > that it's hard to "codify a spirit", but it could be useful to have
> > explicit expectations and guidelines written down somewhere. It could be
> as
> > simple as asking reviewers to "Request Changes" if they want to block a
> PR,
> > or advising authors to wait a couple of days before merging a PR they
> view
> > as complex.
> >
> > --EM
> >
> > On Mon, Mar 24, 2025 at 11:13 AM Yufei Gu  wrote:
> >
> > > I'm particularly concerned about what happened in PR #1230(
> > > https://github.com/apache/polaris/pull/1230). The PR was merged
> despite
> > > multiple unresolved comments from a committer.
> > >
> > > To maintain a healthy review process, we’d like to encourage PR authors
> > to
> > > address open comments and work toward consensus. If necessary, relying
> on
> > > lazy consensus is fine.
> > >
> > > Let’s all try to be mindful of this going forward to ensure smooth
> > > collaboration.
> > >
> > > Yufei
> > >
> > >
> > > On Mon, Mar 24, 2025 at 1:55 AM Jean-Baptiste Onofré 
> > > wrote:
> > >
> > > > Hi Eric,
> > > >
> > > > Thanks for pointing this out.
> > > >
> > > > I think that's unfortunate, especially for #1230 (I don't see issues
> > > > on #1226 and #1220 as they have been approved by 3 different
> > > > committers).
> > > >
> > > > I strongly believe that, as a community, we do a great work all
> > > > together, and we highly consider comments from each other.
> > > > If again, I think it's unfortunate for #1230, it's certainly a
> > > > "mistake" from the author/merger and we should still give a change to
> > > > our soft rules (before being stricter).
> > > >
> > > > So, I propose to continue with our soft rules and good intentions,
> and
> > > > if it doesn't work, then we can discuss about a stricter approach.
> > > >
> > > > Thoughts ?
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > On Sun, Mar 23, 2025 at 8:05 AM Eric Maynard <
> eric.w.mayn...@gmail.com
> > >
> > > > wrote:
> > > > >
> > > > > Revisiting this thread, I wonder if the "soft rules" are working. I
> > > have
> > > > > noticed quite a few PRs merged recently with outstanding comments.
> > The
> > > > most
> > > > > recent of these that I personally reviewed are #1220
> > > > > , #1226
> > > > > , and #1230
> > > > >  but there are
> > doubtless
> > > > other
> > > > > examples.
> > > > >
> > > > > If, indeed, the guidelines are not working perhaps stricter
> > enforcement
> > > > > more consistent with JB's initial proposal would be effective.
> > > > >
> > > > > On Fri, Jan 24, 2025 at 8:21 AM Dmitri Bourlatchkov
> > > > >  wrote:
> > > > >
> > > > > > On Thu, Jan 23, 2025 at 5:15 AM Jean-Baptiste Onofré <
> > > j...@nanthrax.net>
> > > > > > wrote:
> > > > > >
> > > > > > > Let's rename from "guidelines" to "good practices & advices" :)
> > > > > > >
> > > > > >
> > > > > > +1 to that. I'm not sure it worth trying to "codify a spirit"
> (from
> > > > > > previous emails), but
> > > > > > I think having good advice is helpful to instill the spirit of
> > > > goodwill and
> > > > > > collaboration
> > > > > > into the community.
> > > > > >
> > > > > > In this regard:
> > > > > > > - I propose to create a PR to update the contributing guide
> with
> > > this
> > > > > > > good practices discussed in this thread
> > > > > > >
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > - I propose to close https://github.com/apache/polaris/pull/840
> in
> > > > > > > favor of "soft rule" (we quickly discuss about owner review
> with
> > > > > > >
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > CODEOWNERS in this PR, but let's keep aside for now)
> > > > > > > - I propose to update
> https://github.com/apache/polaris/pull/839
> > .
> > > We
> > > > > > > have a consensus about the label, but no consensus about the
> > > schedule
> > > > > > > for now. In order to move forward, I propose to update the PR
> > with
> > > > > > > just the label for now (as we have a consensu

Re: [ANNOUNCE] Welcome Dmitri Bourlatchkov, Dennis Huo and Yufei Gu to the Apache Polaris PPMC

[Robert Stupp]

Congrats!

On 26.03.25 22:47, Russell Spitzer wrote:

Hi y'all!

I'm excited to let the Polaris Community know that the PPMC has added three
new members.  Dmitri Bourlatchkov, Dennis Huo and Yufei Gu are all now
members of the Polaris PPMC.

Please join me in welcoming them,
Russ


--
Robert Stupp
@snazy

Re: [ANNOUNCE] Welcome Dmitri Bourlatchkov, Dennis Huo and Yufei Gu to the Apache Polaris PPMC

[Alex Dutra]

Congratulations to you all, very well deserved!!

Alex

Le jeu. 27 mars 2025 à 06:45, Jean-Baptiste Onofré  a
écrit :

> Congrats !
>
> Regards
> JB
>
> Le mer. 26 mars 2025 à 22:47, Russell Spitzer 
> a
> écrit :
>
> > Hi y'all!
> >
> > I'm excited to let the Polaris Community know that the PPMC has added
> three
> > new members.  Dmitri Bourlatchkov, Dennis Huo and Yufei Gu are all now
> > members of the Polaris PPMC.
> >
> > Please join me in welcoming them,
> > Russ
> >
>

Re: [ANNOUNCE] Welcome Dmitri Bourlatchkov, Dennis Huo and Yufei Gu to the Apache Polaris PPMC

[Anurag Mantripragada]

Congratulations all. Great work!


~ Anurag Mantripragada

> On Mar 27, 2025, at 7:56 AM, Dmitri Bourlatchkov  wrote:
> 
> Thanks all for the warm welcome :)
> 
> Cheers,
> Dmitri.
> 
> On Wed, Mar 26, 2025 at 5:47 PM Russell Spitzer 
> wrote:
> 
>> Hi y'all!
>> 
>> I'm excited to let the Polaris Community know that the PPMC has added three
>> new members.  Dmitri Bourlatchkov, Dennis Huo and Yufei Gu are all now
>> members of the Polaris PPMC.
>> 
>> Please join me in welcoming them,
>> Russ
>> 

Re: [ANNOUNCE] Welcome Dmitri Bourlatchkov, Dennis Huo and Yufei Gu to the Apache Polaris PPMC

[Talat Uyarer]

Congrats folks!

On Thu, Mar 27, 2025 at 10:35 AM Rulin Xing  wrote:

> Congrats folks!
>
> Rulin
>

Re: [ANNOUNCE] Welcome Dmitri Bourlatchkov, Dennis Huo and Yufei Gu to the Apache Polaris PPMC

[Rulin Xing]

Congrats folks!

Rulin

Re: Donate Nessie Iceberg Catalog migrator

[Ajantha Bhat]

Hey everyone, I have the initial PR up in the `polaris-tools` repo.
It has multiple commits for easy review.

https://github.com/apache/polaris-tools/pull/1

Once we have Apache polaris release/nightly build, I will add Apache
polaris integration tests and update the README with polaris examples.

- Ajantha

On Fri, Feb 28, 2025 at 3:30 PM Jean-Baptiste Onofré 
wrote:

> I renamed the repo to https://github.com/apache/polaris-tools
>
> Regards
> JB
>
> Le mer. 26 févr. 2025 à 15:22, Dmitri Bourlatchkov  a
> écrit :
>
> > "polaris-tools" SGTM.
> >
> > Cheers,
> > Dmitri.
> >
> > On Wed, Feb 26, 2025 at 5:15 AM Jean-Baptiste Onofré 
> > wrote:
> >
> > > Yes, we have to keep polaris in the repo name to clearly state it
> > > belongs to Polaris (remember we are directly in the apache org
> > > https://github.com/apache).
> > >
> > > polaris-tools is fine for me. I honestly think it won't stay there
> > > super long, and these "tools" will probably be used in federated
> > > catalogs or foreign tables (just guessing :)).
> > >
> > > Let me rename the repo (or recreate it).
> > >
> > > Thanks everyone,
> > > Regards
> > > JB
> > >
> > > On Wed, Feb 26, 2025 at 7:24 AM Yufei Gu  wrote:
> > > >
> > > > "polaris-tools" sounds good to me. I assume it's not only used by
> > > > developers.
> > > >
> > > > Yufei
> > > >
> > > >
> > > > On Tue, Feb 25, 2025 at 10:56 PM Ajantha Bhat  >
> > > wrote:
> > > >
> > > > > JB mentioned that it has to have `polaris` in the repo name.
> > > > >
> > > > > How about calling it as `apache/*polaris-dev-tools*`? It can have
> an
> > > > > iceberg catalog migrator CLI, Delta lake catalog migrator CLI, or
> > > something
> > > > > else in the future as part of this repo.
> > > > >
> > > > > I don't want the repo to be called just
> > > `apache/polaris-catalog-migrator`
> > > > > because it sounds like it is just a migrator from/to polaris
> catalog.
> > > > >
> > > > > - Ajantha
> > > > >
> > >
> >
>

Re: [DISCUSS] Preparing 0.10.0 release including binary distributions

[Jean-Baptiste Onofré]

Hi everyone

I opened the PR to fix LICENSE/NOTICE in our polaris server and admin
distributions:

https://github.com/apache/polaris/pull/1258

I'm now verifying LICENSE/NOTICE in our distributed artifacts (on
Maven). I will open a PR today.

When these two PRs will be merged, I will move forward on the release.

Thanks,
Regards
JB

On Fri, Mar 14, 2025 at 10:58 AM Jean-Baptiste Onofré  wrote:
>
> Hi folks,
>
> We are working on the 1.0.0 release, with a lot of new features and fixes.
>
> One important change between 0.9.0 and 1.0.0 is the publication of the
> binary distributions, with all related requirements (LICENSE/NOTICE,
> etc).
> I'm working on the LICENSE/NOTICE and binary distributions publication.
> Considering the time we needed to complete the 0.9.0 release, I think
> it would be great to "anticipate" a little before 1.0.0. It would
> allow us to "accelerate" on the 1.0.0 release and beyond.
>
> I would like to propose the 0.10.0 release, as an "intermediate"
> release. I would like to prepare this release by the end of next week,
> creating the 0.10.x branch (based on the main branch) on Saturday,
> March 22 and cutting the 0.10.0 release on Monday, March 24.
>
> Thoughts ?
>
> Regards
> JB

Re: [ANNOUNCE] Welcome Dmitri Bourlatchkov, Dennis Huo and Yufei Gu to the Apache Polaris PPMC

[Honah J.]

Congratulations! Well deserved!

Best regards,
Honah (Jonas)

On Thu, Mar 27, 2025 at 10:48 AM Anurag Mantripragada
 wrote:

> Congratulations all. Great work!
>
>
> ~ Anurag Mantripragada
>
> > On Mar 27, 2025, at 7:56 AM, Dmitri Bourlatchkov 
> wrote:
> >
> > Thanks all for the warm welcome :)
> >
> > Cheers,
> > Dmitri.
> >
> > On Wed, Mar 26, 2025 at 5:47 PM Russell Spitzer <
> russell.spit...@gmail.com>
> > wrote:
> >
> >> Hi y'all!
> >>
> >> I'm excited to let the Polaris Community know that the PPMC has added
> three
> >> new members.  Dmitri Bourlatchkov, Dennis Huo and Yufei Gu are all now
> >> members of the Polaris PPMC.
> >>
> >> Please join me in welcoming them,
> >> Russ
> >>
>
>

Re: [ANNOUNCE] Welcome Dmitri Bourlatchkov, Dennis Huo and Yufei Gu to the Apache Polaris PPMC

[Andrew Guterman]

Congrats!

On Thu, Mar 27, 2025 at 11:25 AM Talat Uyarer 
wrote:

> Congrats folks!
>
> On Thu, Mar 27, 2025 at 10:35 AM Rulin Xing  wrote:
>
> > Congrats folks!
> >
> > Rulin
> >
>

Re: [ANNOUNCE] Welcome Dmitri Bourlatchkov, Dennis Huo and Yufei Gu to the Apache Polaris PPMC

[Jean-Baptiste Onofré]

Congrats !

Regards
JB

Le mer. 26 mars 2025 à 22:47, Russell Spitzer  a
écrit :

> Hi y'all!
>
> I'm excited to let the Polaris Community know that the PPMC has added three
> new members.  Dmitri Bourlatchkov, Dennis Huo and Yufei Gu are all now
> members of the Polaris PPMC.
>
> Please join me in welcoming them,
> Russ
>

Re: [PROPOSAL] Improve our "collaboration schema"

[Jean-Baptiste Onofré]

By the way, I propose to set dismiss_stale_review to false. It should keep
the approval and not in stale mode.
https://github.com/apache/infrastructure-asfyaml?tab=readme-ov-file#branchpro

I will submit a PR for that.

Regards
JB

On Thu, Mar 27, 2025 at 10:43 AM Jean-Baptiste Onofré 
wrote:
>
> By the way, I got some questions from some contributors.
>
> "If I approve a PR, and the author is pushing new changes, should I
> re-approve the PR ?"
>
> The answer is no, your previous approval is still there. For instance,
> on this PR https://github.com/apache/polaris/pull/1259, Eric approved,
> after that I pushed a new change, Eric's approval is still there.
>
> Optionally, we can choose to dismiss stale pull request approvals when
> commits are pushed that affect the diff in the pull request. GitHub
> records the state of the diff at the point when a pull request is
> approved. This state represents the set of changes that the reviewer
> approved. If the diff changes from this state (for example, because a
> contributor pushes new changes to the pull request branch or clicks
> Update branch, or because a related pull request is merged into the
> target branch), the approving review is dismissed as stale, and the
> pull request cannot be merged until someone approves the work again.
>
> If we want to "force" re-approval on change, we should use
> dismiss_stale_reviews: true in .asf.yaml.
>
> See
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging
> for details.
>
> I can change the repo configuration if needed.
>
> Regards
> JB
>
> On Thu, Mar 27, 2025 at 8:28 AM Eric Maynard 
wrote:
> >
> > Sounds good to me!
> >
> > On Wed, Mar 26, 2025 at 11:42 PM Jean-Baptiste Onofré 
> > wrote:
> >
> > > Hi Eric
> > >
> > > I agree. I propose:
> > >
> > > 1. To update the contributor good practices on the website to clearly
state
> > > the keywords nit and minor.
> > > 2. For request change, we can use it. For the record, we can bypass
request
> > > change flag if a given number of reviewers approve the PR anyway.
> > >
> > > Thoughts ?
> > >
> > > Regards
> > > JB
> > >
> > > Le mar. 25 mars 2025 à 19:54, Eric Maynard 
a
> > > écrit :
> > >
> > > > In this case I think rather than a mistake, there could simply be
some
> > > > ambiguity around what comments are considered blocking. For
example, I'm
> > > > not sure if a comment prefixed "minor" should be considered
blocking -- I
> > > > would say probably not, but someone else could interpret it
differently.
> > > >
> > > > To that end, I think putting these things in the guidelines could
be wise
> > > > even if there's not a strict enforcement of the guidelines as such.
I
> > > agree
> > > > that it's hard to "codify a spirit", but it could be useful to have
> > > > explicit expectations and guidelines written down somewhere. It
could be
> > > as
> > > > simple as asking reviewers to "Request Changes" if they want to
block a
> > > PR,
> > > > or advising authors to wait a couple of days before merging a PR
they
> > > view
> > > > as complex.
> > > >
> > > > --EM
> > > >
> > > > On Mon, Mar 24, 2025 at 11:13 AM Yufei Gu 
wrote:
> > > >
> > > > > I'm particularly concerned about what happened in PR #1230(
> > > > > https://github.com/apache/polaris/pull/1230). The PR was merged
> > > despite
> > > > > multiple unresolved comments from a committer.
> > > > >
> > > > > To maintain a healthy review process, we’d like to encourage PR
authors
> > > > to
> > > > > address open comments and work toward consensus. If necessary,
relying
> > > on
> > > > > lazy consensus is fine.
> > > > >
> > > > > Let’s all try to be mindful of this going forward to ensure smooth
> > > > > collaboration.
> > > > >
> > > > > Yufei
> > > > >
> > > > >
> > > > > On Mon, Mar 24, 2025 at 1:55 AM Jean-Baptiste Onofré <
j...@nanthrax.net>
> > > > > wrote:
> > > > >
> > > > > > Hi Eric,
> > > > > >
> > > > > > Thanks for pointing this out.
> > > > > >
> > > > > > I think that's unfortunate, especially for #1230 (I don't see
issues
> > > > > > on #1226 and #1220 as they have been approved by 3 different
> > > > > > committers).
> > > > > >
> > > > > > I strongly believe that, as a community, we do a great work all
> > > > > > together, and we highly consider comments from each other.
> > > > > > If again, I think it's unfortunate for #1230, it's certainly a
> > > > > > "mistake" from the author/merger and we should still give a
change to
> > > > > > our soft rules (before being stricter).
> > > > > >
> > > > > > So, I propose to continue with our soft rules and good
intentions,
> > > and
> > > > > > if it doesn't work, then we can discuss about a stricter
approach.
> > > > > >
> > > > > > Thoughts ?
> > > > > >
> > > > > > Regards
> > > > > > JB
> > > > > >
> > > > > > On Sun, Mar 23, 2025 at 8:05 AM Eric Maynard <
> > > eric.w.mayn...@gmail.com
> > > > >
> > > > > > wr

Re: Polaris-XTable Proposal

[Eric Maynard]

Hey Rahil! Thanks for bringing this up.

My understanding is that we plan to do this through generic tables. I have
this old design doc, but I haven't done anything with it yet because we're
working our way through the initial generic tables implementation:
https://docs.google.com/document/d/1eZQbwgAx1wzjIYtLIdGg8IKQyw7uR-zN50efJ-Hj5XE/edit?usp=sharing

Once we have a better understanding of what generic tables will look like,
I think we should plan to meet and discuss conversion and the role XTable
can play in it.

--EM

On Wed, Mar 19, 2025 at 8:51 AM Jean-Baptiste Onofré 
wrote:

> Hi Rahil
>
> Welcome !
>
> And thanks a lot for your proposal ! It looks very interesting (ok,
> I'm a bit biased as Apache XTable mentor :)).
>
> Let me take a look on the document (and comment directly there).
>
> Thanks again!
>
> Regards
> JB
>
> On Wed, Mar 19, 2025 at 4:00 PM Rahil C  wrote:
> >
> > Hi all,
> >
> > My name is Rahil Chertara, and I’m a part of the Data Infra team at
> > Onehouse.
> >
> > Recently I saw the Roadmap
> >  for Apache Polaris,
> > and became interested in the proposal of Generic Tables and Delta
> Support.
> > I am interested in understanding the Polaris community's vision for
> > supporting open table formats like Delta and Hudi, and was wondering if
> > Polaris will be handling metadata translation/conversion between table
> > formats, as mentioned by this overview doc
> > <
> https://docs.google.com/document/d/1H2StuZ26LroibuQni3IJlErlKgrV9fEvYLHHqN7HWfE/edit?tab=t.0#heading=h.b956txtpu769
> >
> > ?
> >
> > In order to assist in this conversation, I wanted to share a proposal
> with
> > the Polaris community on leveraging Apache XTable for handling this
> > metadata conversion piece.
> >
> > Link to my proposal:
> >
> https://docs.google.com/document/d/1gHM9Qco83EFTTAfByyN3hYLLCghuackL5ogC2T1M074/edit?usp=sharing
> >
> > Appreciate any thoughts and feedback from the community and am also open
> to
> > discuss this in one of the upcoming community syncs.
> >
> > Regards,
> > Rahil Chertara
>

Re: [PROPOSAL] Improve our "collaboration schema"

[Jean-Baptiste Onofré]

I created https://github.com/apache/infrastructure-asfyaml/pull/55

Long story short (after investigation): we have a specific
configuration on Polaris GitHub repo ("Require Last Push Approval")
that is coming from our previous GitHub repository (as reminder, when
Polaris has been accepted into the incubator, we "moved" our GitHub
repo to ASF, we didn't start from a fresh repo). As this configuration
was not "supported" by .asf.yaml, it was not "overwritten" by
.asf.yaml.

I added the support of require_last_push_approval to .asf.yaml to
"control" this configuration.
I gonna create a PR to test this configuration on Polaris ;)

Regards
JB

On Thu, Mar 27, 2025 at 2:10 PM Jean-Baptiste Onofré  wrote:
>
> Quick update: I had a quick chat with Daniel (from Infra) and it seems
> that there's a new "configuration" added recently by GitHub.
> We are updating asf.yaml to support this new feature and I will test.
>
> I will keep you posted :)
>
> Regards
> JB
>
> On Thu, Mar 27, 2025 at 1:05 PM Jean-Baptiste Onofré  
> wrote:
> >
> > By the way, I propose to set dismiss_stale_review to false. It should keep 
> > the approval and not in stale mode.
> > https://github.com/apache/infrastructure-asfyaml?tab=readme-ov-file#branchpro
> >
> > I will submit a PR for that.
> >
> > Regards
> > JB
> >
> > On Thu, Mar 27, 2025 at 10:43 AM Jean-Baptiste Onofré  
> > wrote:
> > >
> > > By the way, I got some questions from some contributors.
> > >
> > > "If I approve a PR, and the author is pushing new changes, should I
> > > re-approve the PR ?"
> > >
> > > The answer is no, your previous approval is still there. For instance,
> > > on this PR https://github.com/apache/polaris/pull/1259, Eric approved,
> > > after that I pushed a new change, Eric's approval is still there.
> > >
> > > Optionally, we can choose to dismiss stale pull request approvals when
> > > commits are pushed that affect the diff in the pull request. GitHub
> > > records the state of the diff at the point when a pull request is
> > > approved. This state represents the set of changes that the reviewer
> > > approved. If the diff changes from this state (for example, because a
> > > contributor pushes new changes to the pull request branch or clicks
> > > Update branch, or because a related pull request is merged into the
> > > target branch), the approving review is dismissed as stale, and the
> > > pull request cannot be merged until someone approves the work again.
> > >
> > > If we want to "force" re-approval on change, we should use
> > > dismiss_stale_reviews: true in .asf.yaml.
> > >
> > > See 
> > > https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging
> > > for details.
> > >
> > > I can change the repo configuration if needed.
> > >
> > > Regards
> > > JB
> > >
> > > On Thu, Mar 27, 2025 at 8:28 AM Eric Maynard  
> > > wrote:
> > > >
> > > > Sounds good to me!
> > > >
> > > > On Wed, Mar 26, 2025 at 11:42 PM Jean-Baptiste Onofré 
> > > > 
> > > > wrote:
> > > >
> > > > > Hi Eric
> > > > >
> > > > > I agree. I propose:
> > > > >
> > > > > 1. To update the contributor good practices on the website to clearly 
> > > > > state
> > > > > the keywords nit and minor.
> > > > > 2. For request change, we can use it. For the record, we can bypass 
> > > > > request
> > > > > change flag if a given number of reviewers approve the PR anyway.
> > > > >
> > > > > Thoughts ?
> > > > >
> > > > > Regards
> > > > > JB
> > > > >
> > > > > Le mar. 25 mars 2025 à 19:54, Eric Maynard  
> > > > > a
> > > > > écrit :
> > > > >
> > > > > > In this case I think rather than a mistake, there could simply be 
> > > > > > some
> > > > > > ambiguity around what comments are considered blocking. For 
> > > > > > example, I'm
> > > > > > not sure if a comment prefixed "minor" should be considered 
> > > > > > blocking -- I
> > > > > > would say probably not, but someone else could interpret it 
> > > > > > differently.
> > > > > >
> > > > > > To that end, I think putting these things in the guidelines could 
> > > > > > be wise
> > > > > > even if there's not a strict enforcement of the guidelines as such. 
> > > > > > I
> > > > > agree
> > > > > > that it's hard to "codify a spirit", but it could be useful to have
> > > > > > explicit expectations and guidelines written down somewhere. It 
> > > > > > could be
> > > > > as
> > > > > > simple as asking reviewers to "Request Changes" if they want to 
> > > > > > block a
> > > > > PR,
> > > > > > or advising authors to wait a couple of days before merging a PR 
> > > > > > they
> > > > > view
> > > > > > as complex.
> > > > > >
> > > > > > --EM
> > > > > >
> > > > > > On Mon, Mar 24, 2025 at 11:13 AM Yufei Gu  
> > > > > > wrote:
> > > > > >
> > > > > > > I'm particularly concerned about what happened in PR #1230(
> > > > > > > https://github.com/apache/polaris/pull/1230). The PR was merged
> > > > > 

Re: [PROPOSAL] Improve our "collaboration schema"

[Jean-Baptiste Onofré]

Quick update: I had a quick chat with Daniel (from Infra) and it seems
that there's a new "configuration" added recently by GitHub.
We are updating asf.yaml to support this new feature and I will test.

I will keep you posted :)

Regards
JB

On Thu, Mar 27, 2025 at 1:05 PM Jean-Baptiste Onofré  wrote:
>
> By the way, I propose to set dismiss_stale_review to false. It should keep 
> the approval and not in stale mode.
> https://github.com/apache/infrastructure-asfyaml?tab=readme-ov-file#branchpro
>
> I will submit a PR for that.
>
> Regards
> JB
>
> On Thu, Mar 27, 2025 at 10:43 AM Jean-Baptiste Onofré  
> wrote:
> >
> > By the way, I got some questions from some contributors.
> >
> > "If I approve a PR, and the author is pushing new changes, should I
> > re-approve the PR ?"
> >
> > The answer is no, your previous approval is still there. For instance,
> > on this PR https://github.com/apache/polaris/pull/1259, Eric approved,
> > after that I pushed a new change, Eric's approval is still there.
> >
> > Optionally, we can choose to dismiss stale pull request approvals when
> > commits are pushed that affect the diff in the pull request. GitHub
> > records the state of the diff at the point when a pull request is
> > approved. This state represents the set of changes that the reviewer
> > approved. If the diff changes from this state (for example, because a
> > contributor pushes new changes to the pull request branch or clicks
> > Update branch, or because a related pull request is merged into the
> > target branch), the approving review is dismissed as stale, and the
> > pull request cannot be merged until someone approves the work again.
> >
> > If we want to "force" re-approval on change, we should use
> > dismiss_stale_reviews: true in .asf.yaml.
> >
> > See 
> > https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging
> > for details.
> >
> > I can change the repo configuration if needed.
> >
> > Regards
> > JB
> >
> > On Thu, Mar 27, 2025 at 8:28 AM Eric Maynard  
> > wrote:
> > >
> > > Sounds good to me!
> > >
> > > On Wed, Mar 26, 2025 at 11:42 PM Jean-Baptiste Onofré 
> > > wrote:
> > >
> > > > Hi Eric
> > > >
> > > > I agree. I propose:
> > > >
> > > > 1. To update the contributor good practices on the website to clearly 
> > > > state
> > > > the keywords nit and minor.
> > > > 2. For request change, we can use it. For the record, we can bypass 
> > > > request
> > > > change flag if a given number of reviewers approve the PR anyway.
> > > >
> > > > Thoughts ?
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > Le mar. 25 mars 2025 à 19:54, Eric Maynard  a
> > > > écrit :
> > > >
> > > > > In this case I think rather than a mistake, there could simply be some
> > > > > ambiguity around what comments are considered blocking. For example, 
> > > > > I'm
> > > > > not sure if a comment prefixed "minor" should be considered blocking 
> > > > > -- I
> > > > > would say probably not, but someone else could interpret it 
> > > > > differently.
> > > > >
> > > > > To that end, I think putting these things in the guidelines could be 
> > > > > wise
> > > > > even if there's not a strict enforcement of the guidelines as such. I
> > > > agree
> > > > > that it's hard to "codify a spirit", but it could be useful to have
> > > > > explicit expectations and guidelines written down somewhere. It could 
> > > > > be
> > > > as
> > > > > simple as asking reviewers to "Request Changes" if they want to block 
> > > > > a
> > > > PR,
> > > > > or advising authors to wait a couple of days before merging a PR they
> > > > view
> > > > > as complex.
> > > > >
> > > > > --EM
> > > > >
> > > > > On Mon, Mar 24, 2025 at 11:13 AM Yufei Gu  
> > > > > wrote:
> > > > >
> > > > > > I'm particularly concerned about what happened in PR #1230(
> > > > > > https://github.com/apache/polaris/pull/1230). The PR was merged
> > > > despite
> > > > > > multiple unresolved comments from a committer.
> > > > > >
> > > > > > To maintain a healthy review process, we’d like to encourage PR 
> > > > > > authors
> > > > > to
> > > > > > address open comments and work toward consensus. If necessary, 
> > > > > > relying
> > > > on
> > > > > > lazy consensus is fine.
> > > > > >
> > > > > > Let’s all try to be mindful of this going forward to ensure smooth
> > > > > > collaboration.
> > > > > >
> > > > > > Yufei
> > > > > >
> > > > > >
> > > > > > On Mon, Mar 24, 2025 at 1:55 AM Jean-Baptiste Onofré 
> > > > > > 
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Eric,
> > > > > > >
> > > > > > > Thanks for pointing this out.
> > > > > > >
> > > > > > > I think that's unfortunate, especially for #1230 (I don't see 
> > > > > > > issues
> > > > > > > on #1226 and #1220 as they have been approved by 3 different
> > > > > > > committers).
> > > > > > >
> > > > > > > I strongly believe that, as a community, we do a great wo

Re: Polaris-XTable Proposal

[yun zou]

Hi Rahil,

Thanks a lot for the proposal! It is interesting. As Eric mentioned, we
were also looking into this before, but at that time there wasn't Generic
Table support yet.

Now with the coming support for Generic Tables, other than the conversion
performance, we might also want to look at more into
1) How the end to end workflow will look like for users across different
engines to create tables in one format and load a table in another format
(given that we have both Iceberg and Generic Table support) ?
2) Can the approach be generalized beyond just XTable? XTable is good, but
users/engines may want to hook up with other available conversions.

Really thank you for bringing this up! I think we should definitely find
some time to talk about this in more detail.

Best Regards,
Yun

On Wed, Mar 19, 2025 at 10:23 AM Eric Maynard 
wrote:

> Hey Rahil! Thanks for bringing this up.
>
> My understanding is that we plan to do this through generic tables. I have
> this old design doc, but I haven't done anything with it yet because we're
> working our way through the initial generic tables implementation:
>
> https://docs.google.com/document/d/1eZQbwgAx1wzjIYtLIdGg8IKQyw7uR-zN50efJ-Hj5XE/edit?usp=sharing
>
> Once we have a better understanding of what generic tables will look like,
> I think we should plan to meet and discuss conversion and the role XTable
> can play in it.
>
> --EM
>
> On Wed, Mar 19, 2025 at 8:51 AM Jean-Baptiste Onofré 
> wrote:
>
> > Hi Rahil
> >
> > Welcome !
> >
> > And thanks a lot for your proposal ! It looks very interesting (ok,
> > I'm a bit biased as Apache XTable mentor :)).
> >
> > Let me take a look on the document (and comment directly there).
> >
> > Thanks again!
> >
> > Regards
> > JB
> >
> > On Wed, Mar 19, 2025 at 4:00 PM Rahil C  wrote:
> > >
> > > Hi all,
> > >
> > > My name is Rahil Chertara, and I’m a part of the Data Infra team at
> > > Onehouse.
> > >
> > > Recently I saw the Roadmap
> > >  for Apache
> Polaris,
> > > and became interested in the proposal of Generic Tables and Delta
> > Support.
> > > I am interested in understanding the Polaris community's vision for
> > > supporting open table formats like Delta and Hudi, and was wondering if
> > > Polaris will be handling metadata translation/conversion between table
> > > formats, as mentioned by this overview doc
> > > <
> >
> https://docs.google.com/document/d/1H2StuZ26LroibuQni3IJlErlKgrV9fEvYLHHqN7HWfE/edit?tab=t.0#heading=h.b956txtpu769
> > >
> > > ?
> > >
> > > In order to assist in this conversation, I wanted to share a proposal
> > with
> > > the Polaris community on leveraging Apache XTable for handling this
> > > metadata conversion piece.
> > >
> > > Link to my proposal:
> > >
> >
> https://docs.google.com/document/d/1gHM9Qco83EFTTAfByyN3hYLLCghuackL5ogC2T1M074/edit?usp=sharing
> > >
> > > Appreciate any thoughts and feedback from the community and am also
> open
> > to
> > > discuss this in one of the upcoming community syncs.
> > >
> > > Regards,
> > > Rahil Chertara
> >
>