Re: [DISCUSS] Labels for GitHub issues + PRs

Why do we remove the 1.1.0-blocker? Yufei On Wed, Aug 20, 2025 at 11:15 PM Robert Stupp wrote: > SGTM > > I'm fine with temporary labels. > > If noone objects, I'd go ahead and remove the unused labels plus these: > - 1.0-blocker > - 1.1.0-blocker > - 1.0.0 bug bash > - IdentityRoleFederation

Re: [DISCUSS] Labels for GitHub issues + PRs

I can keep that. But no issue or PR has that label, so it's unused. On Thu, Aug 21, 2025 at 8:20 AM Yufei Gu wrote: > > Why do we remove the 1.1.0-blocker? > > Yufei > > > On Wed, Aug 20, 2025 at 11:15 PM Robert Stupp wrote: > > > SGTM > > > > I'm fine with temporary labels. > > > > If noone obj

Re: [DISCUSS] Labels for GitHub issues + PRs

SGTM I'm fine with temporary labels. If noone objects, I'd go ahead and remove the unused labels plus these: - 1.0-blocker - 1.1.0-blocker - 1.0.0 bug bash - IdentityRoleFederation late on Friday (CEST). On Thu, Aug 21, 2025 at 8:09 AM Jean-Baptiste Onofré wrote: > > Hi > > The proposal is fine

Podling Polaris Report Reminder - September 2025

Dear podling, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 17 September 2025. The report for your podling will form a part of t

Re: [DISCUSS] Labels for GitHub issues + PRs

Hi The proposal is fine, especially about removing unused labels. I think we should not be "too strict" about labels either: it could be helpful to use labels when preparing a release, temporary to the release prep. So, +1 for a cleanup and "long term labels", but "relax" about the use of tempora

Re: Events Community Sync Follow-up Thread

Hi Adnan Thanks for the message with the list of PRs and details. May I propose to create another PR focusing on API updates ? I quickly took a look on the PRs and my understanding is that these PRs update the API. I propose we start with a simple PR focusing on API change (easily to review and d

Re: [DISCUSS] Add a plugin point for extracting storage config from entities

Hi Dmitri It looks good to me. I'm looking forward the PR to have a better understanding of the proposal. Thanks ! Regards JB On Mon, Aug 18, 2025 at 6:08 PM Dmitri Bourlatchkov wrote: > > Hi All, > > Currently Polaris core code has a very specific mechanism for > extracting PolarisStorageConfi

Re: [DISCUSS] Merge Authenticator and ActiveRolesProvider

Hi Alex Thanks for this. Admittedly, the ActiveRolesProvider was *intended* to support the future OIDC/Quarkus support, but that was long before the current HttpAuthenticationMechanism. I'm going to check out this branch and validate, but I think it's a good change. It helps with some changes I h

Re: [RELEASE] 1.1.0-incubating release preparation

Okay, after some analysis I posted in https://github.com/apache/polaris/issues/2325#issuecomment-3208935604 I think it would be sufficient to fix-forward with a FeatureConfiguration determining whether to allow skipping the roleArn so that we can preserve fast-failure behavior in existing multi-ten

Re: Heads-up: role-ARN option for S3 becoming optional

Reposting my comment from the github issue here for further discussion: It seems like there are three distinct "new" use cases: 1. Using DefaultCredentialsProvider directly without subscoping to access storage when running on AWS and using AWS S3 2. Using DefaultCredentialsProvider directly witho

Re: [RELEASE] 1.1.0-incubating release preparation

Can we also highlight the key SPI and internal-API changes that service providers with custom plugins should be aware/reminded of at a glance? In the future perhaps we can use a label or similar on SPI-evolution PRs to better automate aggregating those changes, and also ideally also include SPI ch

Re: [DISCUSS] Labels for GitHub issues + PRs

> Generally, IIRC, we agreed on not using a "blocker label". Where was this? I thought the 1.0-blocker label was quite useful when preparing for the 1.0 release, and I imagined that we'd continue to use something similar for future releases. The closest thing I see is this email

Re: [DISCUSS] Merge Authenticator and ActiveRolesProvider

The confusion between "scopes" and actually *validated* "activatedRoles" is unfortunate. Originally the AuthenticatedPolarisPrincipal really was supposed to only contain "requestedScopes", and grant-resolution was just in the Resolver. In fact I was trying to do some digging to figure out why there

Re: [DISCUSS] Labels for GitHub issues + PRs

I agree with all points and proposed label removal from Robert's email. As for "question", I would not mind keeping it, although, I personally do not see a big difference between a general discussion and a discussion labelled as a "question". Discussions are certainly preferable to issues labelled

Re: [DISCUSSION] Integrations points in Polaris

Good point about the distinction of API and SPI, Pierre! I'd add from my side that I think polaris-core is in the middle of API and SPI. Polaris-core can be used in downstream projects and called via its API (as a library). At the same time downstream projects can plug in different SPI implementat

Re: Re: [DISCUSS] S3 Credential vending without STS

Hi Alex, thanks for adding diagrams. I think the server side caching is valuable so that Polaris doesn’t need to call AWS every time a client asks. It's helpful esp. when a file(e.g., metadata.json, manifest-list, manifest) is "hot" or accessed by multiple clients. For rate limits, I think we wil

Re: [DISCUSSION] Integrations points in Polaris

It would probably be good to separate the API modules, which define what other systems can consume, from SPI modules, which define what other systems can _extend_. Those are two different concerns and could require two distinct sets of dependencies. However I do not think we should consider the c

[DISCUSS] Require changelog updates within applicable PR

Hi folks Creating this thread to avoid hijacking the 1.1.0 release thread. The topic of keeping a change log for breaking changes was already discussed on the dev mailing list [1]. But one point related to ownership of CHANGELOG.md consistency was not addressed [2]. And I would like to revive t

Re: [DISCUSS] Add feature flag: PURGE_VIEWS_ON_DROP

Merged. https://github.com/apache/polaris/pull/2369 On 2025/08/19 18:59:21 Dmitri Bourlatchkov wrote: > I updated PR [2369] to use PURGE_VIEW_METADATA_ON_DROP as the feature flag > name. > > Please review, approve or comment. As I noted previously, I'm open to other > naming suggestions, but thi

Re: [RELEASE] 1.1.0-incubating release preparation

+1 to proactively updating CHANGELOG.md. That is how it was originally envisioned [1] :) [1] https://lists.apache.org/thread/qznf8toht1r7ml35lt4p8nwlk9op638v Cheers, Dmitri. On Wed, Aug 20, 2025 at 6:33 AM Robert Stupp wrote: > Thanks a lot for tackling this, Pierre! > > It's very difficult t

Re: [DISCUSSION] Integrations points in Polaris

I think we could combine annotation-based stability markers with module/package separation. One possible example roadmap could look like this: - Polaris 1.2: mark key interfaces as @Evolving. - Polaris 1.3: move them into a polaris-api module and mark the old locations as @Deprecated. - Polaris 1.

Re: [DISCUSS] Labels for GitHub issues + PRs

Hi Robert, I'm +1 on your proposal, although I could see a valid reason to keep the "question" label as well, even if it's unused. Thanks, Alex On Wed, Aug 20, 2025 at 10:56 AM Robert Stupp wrote: > > Hi all, > > We currently have a lot of GitHub labels for issues and pull requests. > Many of t

Re: [Event API & Interface] Community meeting record and next steps

Thanks for the summary. Really appreciate the focus on the API first, get consensus on that and after that tackle the implementations. Looking forward to the events API proposal! On Tue, Aug 19, 2025 at 8:39 AM Jean-Baptiste Onofré wrote: > > Hi folks, > > Thanks everyone for participating in t

Re: [RELEASE] 1.1.0-incubating release preparation

Thanks a lot for tackling this, Pierre! It's very difficult to figure out all new features, changes and fixes "after the fact". I think we should establish a culture to _proactively_ populate the content of CHANGELOG.md _within_ each applicable PR instead of asking weeks or months later, or havin

Re: [RELEASE] 1.1.0-incubating release preparation

I just opened https://github.com/apache/polaris/pull/2406 with the list of new features that were added in main since the 1.0.x release branch was cut. Would it be possible to get a review to ensure I did not miss any? Note that this only contains features, and not fixes. -- Pierre On Wed, Au

Re: [DISCUSS] Add a plugin point for extracting storage config from entities

Hi, I've been looking into untangling the strong coupling of storage credentials and persistence. Storage (think: S3, GCS, etc), storage credentials and persistence are very different things IMO. This coupling also needs to be removed to allow tasks to be executed "anywhere", without having to loa

Re: [RELEASE] 1.1.0-incubating release preparation

Hi all, Would it be possible to include the below PR in 1.1.0: https://github.com/apache/polaris/pull/2404 This PR deprecates `ActiveRolesProvider`, thus sending a clear message about its future removal while providing integrators with ample time to adjust their implementations accordingly. Rel

[DISCUSS] Labels for GitHub issues + PRs

Hi all, We currently have a lot of GitHub labels for issues and pull requests. Many of the labels serve(d) a temporary purpose, have no clear meaning or are superfluous as GitHub offers more sophisticated approaches. The following list serves as a proposal to apply to the project's list of labels.

Re: Re: [DISCUSS] S3 Credential vending without STS

Hi all, just to clarify: we're not inventing anything new here, but will provide a way to use Iceberg's out-of-the-box ability to let the IRC (Polaris) sign the individual S3 requests. We're not changing anything in that remote S3-request-signing flow, and certainly cannot "magically" add optimiza

Re: [RELEASE] 1.1.0-incubating release preparation

Hi all, I don't see any other changes, besides what's already mentioned, that can make it for the 1.1 "train car". Robert On Wed, Aug 20, 2025 at 12:26 AM Yufei Gu wrote: > > Hi JB, > > Make sense to move some enhancement and proposals to 1.2. e.g., Support for > OpenLineage. Some of 1.1 items