Hi Robert, I understand your perspective on the process and see that your points regarding timing are valid. I suggest we start a separate thread to align on these procedures and update our contribution guidelines if necessary; the community should clearly define the implications of our voting process.
While voting is an effective tool for both visibility and consensus, I generally prefer starting with a discussion to reach lazy consensus on the dev@ mailing list. That said, lazy consensus is an alternative, and it is perfectly acceptable for a committer to initiate a code-modification vote. I view this vote as similar to our previous one regarding OpenAPI return values (https://lists.apache.org/thread/rv3sqno6orfyx7h3f2llb8lkq00zofg8), which is why I believe there is a precedent for this approach with REST/OpenAPI changes. I would like to move forward with my original proposal: let's proceed with the current vote and continue addressing comments within the PR. In the meantime, please feel free to start a new thread specifically to discuss how we handle future REST/OpenAPI change proposals. What do you think? Regards, JB On Fri, Feb 20, 2026 at 10:37 AM Robert Stupp <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
