my +1 too We can consider this vote successful. I just merged the PR.
On Mon, Mar 30, 2026 at 8:23 AM Alexandre Dutra <[email protected]> wrote: > Thanks Ryan! > > With that, is it necessary to start a new vote or can we consider this > one as successful? > > I'm counting so far: > > - 5 binding +1s: Eduard, Matt, Prashant, Daniel, Ryan > - 5 non-binding +1s: Dmitri, Christian, Ajantha, JB and myself. > - No -1s > > Thanks, > Alex > > On Wed, Mar 25, 2026 at 8:23 PM Ryan Blue <[email protected]> wrote: > > > > Yes, this look better now so I'll update my vote to +1. > > > > Thanks, Alex! > > > > On Wed, Mar 25, 2026 at 1:37 AM Alexandre Dutra <[email protected]> > wrote: > >> > >> Hi Ryan, > >> > >> That's a fair point, I've updated the spec to remove the mention of > >> the Java library and the associated removal timeline. > >> > >> Does this address your concerns enough for you to reconsider your vote? > >> > >> Thanks, > >> Alex > >> > >> On Mon, Mar 23, 2026 at 11:42 PM Daniel Weeks <[email protected]> > wrote: > >> > > >> > For migration purposes, this new endpoint should be included with > supported endpoints config response, so newer clients should know if the > catalog supports signing through this new path or should default to the old > behavior. > >> > > >> > I think deprecating the old spec is fine (though agree that maybe the > removal timeline should be reconsidered or simply removed). > >> > > >> > -Dan > >> > > >> > On Mon, Mar 23, 2026, 1:32 PM Ryan Blue <[email protected]> wrote: > >> >> > >> >> -0 > >> >> > >> >> I think the addition to the REST spec is fine, but I don't think the > changes to the old signer spec are correct. First, the old spec now > references the Java library versions and states that support will be > removed in 1.12.0. I think it should be independent from Java versions > since the REST spec is not tied to Java releases -- it's a bit unclear how > we want to handle this with secondary specs, but I doubt that the solution > is to rely on Java library versions. Second, is there a summary of the > discussion where we decided to deprecate this so quickly? I thought that > there were projects that implement remote signing, so how can we expect > people to move in a Java minor release timeframe? What is the plan for > falling back to the old API and for how long? > >> >> > >> >> On Mon, Mar 23, 2026 at 12:37 PM Daniel Weeks <[email protected]> > wrote: > >> >>> > >> >>> With the updates, I'm changing my vote to +1 > >> >>> > >> >>> I believe the vote was already called, so for procedure purposes, > we should probably just start a new vote. > >> >>> > >> >>> -Dan > >> >>> > >> >>> On Thu, Mar 19, 2026 at 9:39 AM Eduard Tudenhöfner < > [email protected]> wrote: > >> >>>> > >> >>>> +1 > >> >>>> > >> >>>> On Wed, Mar 18, 2026 at 6:07 PM Alexandre Dutra <[email protected]> > wrote: > >> >>>>> > >> >>>>> Hi all, > >> >>>>> > >> >>>>> Gentle reminder to review the revised spec changes: > >> >>>>> https://github.com/apache/iceberg/pull/15450 > >> >>>>> > >> >>>>> Thanks, > >> >>>>> Alex > >> >>>>> > >> >>>>> On Fri, Mar 6, 2026 at 5:21 PM Alexandre Dutra <[email protected]> > wrote: > >> >>>>> > > >> >>>>> > Hi all, > >> >>>>> > > >> >>>>> > FYI the required changes were implemented: > >> >>>>> > https://github.com/apache/iceberg/pull/15450 > >> >>>>> > > >> >>>>> > Thanks, > >> >>>>> > Alex > >> >>>>> > > >> >>>>> > On Thu, Mar 5, 2026 at 9:49 AM Alexandre Dutra < > [email protected]> wrote: > >> >>>>> > > > >> >>>>> > > Hi all, > >> >>>>> > > > >> >>>>> > > With one binding -1, the vote does not pass. I will prepare > the > >> >>>>> > > requested changes and start another vote thread when we're > ready. > >> >>>>> > > > >> >>>>> > > Thanks, > >> >>>>> > > Alex > >> >>>>> > > > >> >>>>> > > On Wed, Mar 4, 2026 at 11:12 PM Daniel Weeks < > [email protected]> wrote: > >> >>>>> > > > > >> >>>>> > > > -1 (but I think we can address the concern easily) > >> >>>>> > > > > >> >>>>> > > > I just added a comment to the PR that's a blocker for me. > We introduced an explicit enumeration of cloud providers which I strongly > oppose codifying in the spec. > >> >>>>> > > > > >> >>>>> > > > That limits other providers from leveraging the signing > portion of the spec without a spec change and is unnecessarily strict. > >> >>>>> > > > > >> >>>>> > > > This should be a simple update to address, but I can't > support this change until we remove that. > >> >>>>> > > > > >> >>>>> > > > -Dan > >> >>>>> > > > > >> >>>>> > > > > >> >>>>> > > > > >> >>>>> > > > On Wed, Mar 4, 2026 at 8:44 AM Jean-Baptiste Onofré < > [email protected]> wrote: > >> >>>>> > > >> > >> >>>>> > > >> +1 (non binding) > >> >>>>> > > >> > >> >>>>> > > >> Regards > >> >>>>> > > >> JB > >> >>>>> > > >> > >> >>>>> > > >> On Mon, Mar 2, 2026 at 7:33 AM Alexandre Dutra < > [email protected]> wrote: > >> >>>>> > > >>> > >> >>>>> > > >>> Hi all, > >> >>>>> > > >>> > >> >>>>> > > >>> This is a second vote attempt in order to adopt the > promotion of the > >> >>>>> > > >>> remote signing endpoint to the main REST spec. > >> >>>>> > > >>> > >> >>>>> > > >>> Related links: > >> >>>>> > > >>> > >> >>>>> > > >>> ML thread: > https://lists.apache.org/thread/2kqdqb46j7jww36wwg4txv6pl2hqq9w7 > >> >>>>> > > >>> PR: https://github.com/apache/iceberg/pull/15450 > >> >>>>> > > >>> > >> >>>>> > > >>> Please vote within the next 72 hours. > >> >>>>> > > >>> > >> >>>>> > > >>> [ ] +1 Adopt the promotion of the remote signing endpoint > to the main REST spec > >> >>>>> > > >>> [ ] +0 > >> >>>>> > > >>> [ ] -1 Do not adopt, please explain why > >> >>>>> > > >>> > >> >>>>> > > >>> Thanks, > >> >>>>> > > >>> Alex >
