Hi JB, I'm fine with continuing this vote thread and aligning on spec / API change procedures separately.
As I indicated in my first reply with the -1 vote, I intend to update it once the GH comments are resolved. To be clear: I'm not against adding this API, but I believe the OpenAPI definition in PR [3826] needs some improvements before merging. Therefore, I voted as requested by the vote email: "-1 I have questions and/or concerns". Re: the previously discussed proposal doc, TBH, I do not see an exact definition of the new REST API in it. Examples are present, but it's not the same thing as a spec. So, PR [3826] was the first concrete spec change related to this proposal that I am aware of (I might have missed something, apologies if so). [3826] https://github.com/apache/polaris/pull/3826 Cheers, Dmitri. On Fri, Feb 20, 2026 at 5:47 AM Jean-Baptiste Onofré <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
