Hi I would like to provide two perspectives:
1. This kind of vote is totally fine, because it's considered as a consensus approval. In this scenario, a negative vote constitutes a veto, which the voting group (generally the PMC of a project) cannot override. Again, this model may be modified by a lazy consensus declaration when the request for a vote is raised, but the full-stop nature of a negative vote does not change. Under normal (non-lazy consensus) conditions, the proposal requires three +1 votes and no -1 votes in order to pass; if it fails to garner the requisite amount of support, it doesn't. Then the proposer either withdraws the proposal or modifies the code and resubmits it, or the proposal simply languishes as an open issue until someone gets around to removing it. Unless the proposer declares that the vote is using lazy consensus, three +1 votes are required for a code-modification proposal to pass. 2. Before this vote, we had a discussion about credential vending ini Generic Table ( https://lists.apache.org/thread/9y0xnjfn4n06svkt657gcsplk6sc7dhf). As the PR change the spec, the vote is fair and appropriate here. The PR is "materialize" what is in the proposal document: https://docs.google.com/document/d/1QzTx4tcS23_mF-gc77GbTqtwuRHY5f_Aa_6E4VSKFU4/edit?tab=t.0#heading=h.rpqtaz73xt4v In the "API Spec for Credential Vending" section of the proposal document, I don't see "blocker comments" in the document. So, it's not like the PR is coming from nowhere, the proposal is 3 weeks old and has been shared on the mailing list. We agreed in the past to call a vote for any "user facing" change: API or REST Spec. I don't think we need more. The questions in the PR are certainly addressable quickly (mostly questions about S3/AWS wording in the description section). So, I would suggest keeping this vote open to give visibility to the community and consensus approval, and in the meantime, we update the PR with the comments. The vote is open to 72 hours but it can run longer than that (that's a minimum time). Regards JB On Fri, Feb 20, 2026 at 4:22 AM Dmitri Bourlatchkov <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > >
