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

Reply via email to