Hi Dmitri, Thanks for the reminder — and apologies for jumping to a conclusion earlier. I should have double-checked the exact timing.
Definitely +1 on improving the process. While a VOTE mechanism is likely helpful for critical changes, it does feel a bit tedious for smaller updates like this. Best regards, Yun On Fri, Mar 27, 2026 at 7:02 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi Yun, > > I do not challenge the result of this vote. > > However, process-wise, the vote called for a 72-hour voting period starting > on Mar 25 at 2:49 PM (EDT). So the vote should have been open until Mar > 28 2:49 PM (EDT). > > This is just another point that (in my opinion), formal vote threads on > OpenAPI YAML changes are too cumbersome. We might as well merge upon > receiving approvals in GH after the normal code review period and a simple > awareness email on `dev`. I do not see what we could gain by having an > additional vote waiting period. > > Cheers, > Dmitri. > > On Fri, Mar 27, 2026 at 7:22 PM yun zou <[email protected]> > wrote: > > > Hi Team, > > > > Given that this spec represents a relatively straightforward change and > the > > current vote has passed, I would like to conclude this thread. > > > > We received two votes (2 binding +1, and no -1). I will now proceed with > > the merge. > > > > Best regards, > > Yun > > > > On Wed, Mar 25, 2026 at 1:18 PM Yufei Gu <[email protected]> wrote: > > > > > +1. Thanks Yun! > > > Yufei > > > > > > > > > On Wed, Mar 25, 2026 at 12:02 PM Dmitri Bourlatchkov <[email protected] > > > > > wrote: > > > > > > > +1 (binding) > > > > > > > > Note: I added a "nit" comment about two empty lines in the doc > comment. > > > If > > > > that change is committed, my +1 vote still stands. > > > > > > > > Side note: I personally do not see much value in formal vote threads > on > > > > OpenAPI yaml changes. I believe we can handle them as normal code > > changes > > > > (GH approvals) as long as the change is visible on `dev` in a regular > > > > discussion thread. > > > > > > > > Cheers, > > > > Dmitri. > > > > > > > > On Wed, Mar 25, 2026 at 2:49 PM yun zou <[email protected]> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > To enable credential vending for generic tables, we have > introduced a > > > new > > > > > header, Polaris-Generic-Table-Access-Delegation, in the > > > loadGenericTable > > > > > and createGenericTable requests. This approach is aligned with the > > > > pattern > > > > > used for Iceberg. > > > > > > > > > > I would like to initiate a vote on this API specification change. > > > > > PR to add the API spec: > https://github.com/apache/polaris/pull/4043 > > > > > > > > > > Please vote in the next 72 hours: > > > > > > > > > > [ ] +1 Add these changes to the spec > > > > > [ ] +0 > > > > > [ ] -1 I have questions and/or concerns > > > > > > > > > > Best Regards, > > > > > Yun > > > > > > > > > > > > > > >
