Hi all, Thanks a lot for all the discussion that happened on this topic.
What Yun is asking for is, I think, general consensus on and broader awareness of the public user facing REST API change, which is totally fine! The first email in this thread may appear to call for a code-change vote on the current contents of the mentioned pull request, especially its user facing inline documentation. User facing documentation often raises questions, proposals for improvements and general comments. I tried to find a previous vote thread regarding a public facing REST API change, but could not find one. So I think this is the first time this has happened. As with all new things, mistakes and misunderstandings can happen on any side. The ASF has pretty strict rules for votes [1], which require defining the scope of the vote and the meaning of the (+1/0/-1) votes. It's a very formal process that allows little room for interpretation. A binding -1, raised due to a question or concern, as stated in the initial email, blocks both the proposal and the voted-on PR until it is withdrawn, as proposed in the vote. As a proposal to move forward, I suggest halting this vote, addressing the comments on the PR, and potentially on the proposal document if there are open concerns, and then restarting the vote clock. If people feel that stopping and restarting the "vote clock" is inappropriate, cancelling this vote and starting a new one later is a possible alternative. For the future, I propose relaxing the timing a little bit. If people feel that an "awareness vote" is needed, perhaps open the PR and maybe send a "vote coming heads-up" to the mailing list first to give people some time to review the actual code changes. After that, call for the vote. But I also propose being stricter about the meaning of votes: like ask for "+1: I agree to the PR as it stands" and "-1: I do not agree, because of technical issues, justification is required." and "0: (I don't care?)" in the vote. A formal process definition is not required in my opinion. We, the Polaris project, acknowledge that many of our contributors dedicate their weekend time to relax [2] and start the next week with a fresh mind. What I'm trying to say is: it's Friday, so don't start your well deserved weekend with a heated mind ;) I think our community can learn from this experience and I am confident we can resolve this and improve in the future. Cheers, Robert [1] https://www.apache.org/foundation/voting.html [2] https://polaris.apache.org/community/contributing-guidelines/#code-contribution-guidelines On Fri, Feb 20, 2026 at 6:57 AM Jean-Baptiste Onofré <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
