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 > > > > > > > > > >
