I do not mind using VOTE threads for more rigorous approvals. My point was only that it makes sense to start a vote after the change (PR) reaches a stable state (implying it has been reviewed).
>From my personal POV, a "DISCUSS" thread provides enough visibility and GH tracks approvals for other code changes anyway. The only difference is that GH does not distinguish between PMC and Committer votes, but this doesn't matter in Polaris since the general agreement is to treat all comments / concerns as blocking until they are resolved [1]. It might be worthwhile starting a separate discussion about how we approach REST API changes just to bring everyone onto the same page and update [1] [1] https://polaris.apache.org/community/contributing-guidelines/ Cheers, Dmitri. On Thu, Feb 19, 2026 at 9:02 PM Russell Spitzer <[email protected]> wrote: > So no vote threads on changes? Just PR reviews? That's fine if it's worked > well in the past. We > had done this for Iceberg so folks would have a heads up when things were > going to change even > if they weren't following the specific discussion or PR, but we don't have > to do that here. > > On Thu, Feb 19, 2026 at 6:25 PM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi Russell, > > > > That's probably where people's perceptions differ :) > > > > I would have expected a GH review first, followed by a formal vote once > the > > reviews are positive. As for me, voting should happen on a stable change > > set, but in this case the PR is likely to change. If/when that happens a > > new VOTE would be in order (as for a new RC). > > > > That said, we've had a few cases where a REST API change got a DISCUSSION > > email thread and formal approvals in GH (without a VOTE thread). As I > > recall, this has been the prevalent pattern so far. From my POV we might > as > > well cancel this vote and start a DISCUSSION thread instead (linking to > > previous proposal emails), with a notice that approvals are to be done in > > GH. WDYT? > > > > Cheers, > > Dmitri. > > > > On Thu, Feb 19, 2026 at 3:47 PM Russell Spitzer < > [email protected] > > > > > wrote: > > > > > I generally thought a +1 here is basically a go ahead to merge the PR > > > whenever it has sufficient reviews as we have approved the concept. > > > > > > On Thu, Feb 19, 2026 at 1:09 PM Dmitri Bourlatchkov <[email protected]> > > > wrote: > > > > > > > Hi Yun, > > > > > > > > Thanks for opening the spec change PR! > > > > > > > > I wonder if this vote call might have been a bit premature... before > > the > > > PR > > > > received reviews in GH... In any case I left some comments in GH. > > > > > > > > Voting -1 (binding) for now as explained in GH comments. Will update > my > > > > vote after GH comments are discussed. > > > > > > > > Cheers, > > > > Dmitri. > > > > > > > > On Wed, Feb 18, 2026 at 8:19 PM yun zou <[email protected]> > > > > wrote: > > > > > > > > > Hi All, > > > > > > > > > > Given the growing interest in Generic Table, I propose adding > > > credential > > > > > vending support to further enhance its data governance > capabilities. > > > > > > > > > > The detailed discussion has taken place in a separate thread. I > would > > > now > > > > > like to call for a vote to adopt the storage credential API > > > > specification, > > > > > which clearly documents the storage configurations supported by > > Polaris > > > > in > > > > > its description. > > > > > > > > > > Thank you all for your reviews and feedback. > > > > > > > > > > Please refer to the link below for additional details: > > > > > - Spec change PR: https://github.com/apache/polaris/pull/3826 > > > > > - Related Issue: https://github.com/apache/polaris/issues/3020 > > > > > - Discussion thread: > > > > > https://lists.apache.org/thread/9y0xnjfn4n06svkt657gcsplk6sc7dhf > > > > > > > > > > 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 > > > > > > > > > > > > > > >
