Thanks everyone who participated in the vote for Release Apache Iceberg
1.9.1 RC1.
The vote result is:
+1: 3 (binding), 5 (non-binding). {Russell, Steven Wu, Fokko} | {JB,
Karuppayya, Kevin, Huaxin, Aihua}
+0: 0 (binding), 0 (non-binding)
-1: 0 (binding), 0 (non-binding)
Therefore, the release candidate is passed.
On Tue, May 27, 2025 at 1:28 PM Aihua Xu <aihu...@gmail.com> wrote:
> +1 (non-binding).
>
> Verified against Snowflake engine.
>
> On Tue, May 27, 2025 at 9:28 AM huaxin gao <huaxin.ga...@gmail.com> wrote:
>
>> +1 (non-binding)
>> Verified signature, checksum, license and ran some tests.
>>
>> On Tue, May 27, 2025 at 9:06 AM Russell Spitzer <
>> russell.spit...@gmail.com> wrote:
>>
>>> For all those who haven't seen this before, GPG key signing is a very
>>> "early hacker" sort of thing. The idea is the only way to trust a signature
>>> is to
>>> have it signed by someone that you also trust. This builds a network of
>>> trust so you could essentially do something like say I trust that key X is
>>> Russell
>>> and therefore trust that Key Y signed by Key X is also trusted to be
>>> whoever they say they are because you trust Russell and his key. I don't
>>> think folks do
>>> this all that often any more but never fear, our current process is not
>>> "completely" anonymous.
>>>
>>> When you download the KEYS file from SVN you are downloading what is
>>> essentially a list of Public Keys and Identities that is updated only by
>>> folks
>>> with valid Apache SVN credentials so there is a bit of security there.
>>>
>>> All of that to say, yes that key is mine and if you trust that this
>>> email comes from me, you can trust that key is also me. If you don't trust
>>> this email ...
>>> send me a message and I can 1 on 1 verify with you on video (although
>>> with AI who knows) that I am Russell and that is my key. I'll be in SF in
>>> person next week for Snowflake Summit if anyone wants in person
>>> validation :)
>>>
>>>
>>> On Tue, May 27, 2025 at 10:38 AM Kevin Liu <kevinjq...@apache.org>
>>> wrote:
>>>
>>>> +1 (non-binding)
>>>>
>>>> - Verified signature, checksum, license.
>>>> * Build + test passed using Java 17 on M1
>>>> * Ran a few examples on Spark
>>>> * Ran pyiceberg integration tests
>>>>
>>>> Best,
>>>> Kevin Liu
>>>>
>>>> On Tue, May 27, 2025 at 7:59 AM karuppayya <karuppayya1...@gmail.com>
>>>> wrote:
>>>>
>>>>> When verifying
>>>>> <https://iceberg.apache.org/how-to-release/#verifying-signatures>
>>>>> signatures. I got a warning. Am I missing something with the gpg
>>>>> configuration?
>>>>>
>>>>> gpg: assuming signed data in 'apache-iceberg-1.9.1.tar.gz'
>>>>> gpg: Signature made Wed May 21 15:19:17 2025 PDT
>>>>> gpg: using RSA key xxx
>>>>> gpg: Good signature from "Russell Spitzer (CODE SIGNING KEY)
>>>>> <russellspit...@apache.org>" [unknown]
>>>>> gpg: WARNING: This key is not certified with a trusted signature!
>>>>> gpg: There is no indication that the signature belongs to the
>>>>> owner.
>>>>> Primary key fingerprint: x
>>>>>
>>>>>
>>>>> Verified checksums, local build and ran basic tests on Spark 3.5.
>>>>>
>>>>> If the warning is ok to ignore,
>>>>> +1 (non-binding)
>>>>>
>>>>> - Karuppayya
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 27, 2025 at 7:29 AM Jean-Baptiste Onofré <j...@nanthrax.net>
>>>>> wrote:
>>>>>
>>>>>> +1 (non binding)
>>>>>>
>>>>>> I checked:
>>>>>> * source distribution
>>>>>> ** checksum and signature are good
>>>>>> ** LICENSE and NOTICE look good
>>>>>> ** No binary file found in the source distribution
>>>>>> ** Header looks good in files
>>>>>> ** Build works from the source distribution
>>>>>> ** Tested with Spark and Polaris
>>>>>> * in the bundled jar files:
>>>>>> ** aws-bundle jar contains correct LICENSE/NOTICE
>>>>>> ** azure-bundle jar contains LICENSE/NOTICE, nit: Azure MIT license
>>>>>> content should be part of the LICENSE (inline). I will fix that.
>>>>>> ** gcp-bundle jar contains LICENSE/NOTICE, nit: Google BSD 3-Clause
>>>>>> license content should be part of the LICENSE (inline), and some
>>>>>> dependencies have dual licenses, only one should be "selected" in
>>>>>> Iceberg (exclusive). I will fix that.
>>>>>> ** kafka-runtime (main and hive) contains LICENSE/NOTICE, nit: same
>>>>>> issue as in azure-bundle and gcp-bundle about exclusive license and
>>>>>> MIT/BSD license content
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On Thu, May 22, 2025 at 1:19 AM Russell Spitzer
>>>>>> <russell.spit...@gmail.com> wrote:
>>>>>> >
>>>>>> > Hi Y'all,
>>>>>> >
>>>>>> > I propose that we release the following RC as the official Apache
>>>>>> Iceberg 1.9.1 release.
>>>>>> >
>>>>>> > The commit ID is f40208ae6fb2f33e578c2637d3dea1db18739f31
>>>>>> > * This corresponds to the tag: apache-iceberg-1.9.1-rc1
>>>>>> > *
>>>>>> https://github.com/apache/iceberg/commits/apache-iceberg-1.9.1-rc1
>>>>>> > *
>>>>>> https://github.com/apache/iceberg/tree/f40208ae6fb2f33e578c2637d3dea1db18739f31
>>>>>> >
>>>>>> > The release tarball, signature, and checksums are here:
>>>>>> > *
>>>>>> https://dist.apache.org/repos/dist/dev/iceberg/apache-iceberg-1.9.1-rc1
>>>>>> >
>>>>>> > You can find the KEYS file here:
>>>>>> > * https://downloads.apache.org/iceberg/KEYS
>>>>>> >
>>>>>> > Convenience binary artifacts are staged on Nexus. The Maven
>>>>>> repository URL is:
>>>>>> > *
>>>>>> https://repository.apache.org/content/repositories/orgapacheiceberg-1202/
>>>>>> >
>>>>>> > Please download, verify, and test.
>>>>>> >
>>>>>> > Please vote in the next 72 hours.
>>>>>> >
>>>>>> > [ ] +1 Release this as Apache Iceberg 1.9.1
>>>>>> > [ ] +0
>>>>>> > [ ] -1 Do not release this because...
>>>>>> >
>>>>>> > Only PMC members have binding votes, but other community members
>>>>>> are encouraged to cast
>>>>>> > non-binding votes. This vote will pass if there are 3 binding +1
>>>>>> votes and more binding
>>>>>> > +1 votes than -1 votes.
>>>>>> >
>>>>>> > ---
>>>>>> >
>>>>>> > For those watching the big change between this and RC0 was the
>>>>>> reversion of code which
>>>>>> > caused the rest client to emit multiple Snapshot Removals Requests
>>>>>> in the same MetadataUpdate.
>>>>>> > This restores the behavior to that of 1.8.X, 1 removal per update.
>>>>>> > We plan to move to the new behavior in a later release
>>>>>>
>>>>>
