Re: [DISCUSS] PyIceberg 0.7.1 release

2024-08-09 Thread Fokko Driesprong
Hey Sung, That's a great find. I just merged the PR, and it would be good to get the release process rolling to get #1026 out to the users. Kind regards, Fokko Op do 8 aug 2024 om 23:20 schreef Sung Yun : > Thank you for reporting the issues

Re: [DISCUSS] PyIceberg 0.7.1 release

2024-08-09 Thread Sung Yun
Agreed Fokko :) I've cherry-picked the commits in the 0.7.1 milestone into a new branch, and created this PR: https://github.com/apache/iceberg-python/pull/1031 If this looks good, I can start the release for 0.7.1. Sung On Fri, Aug 9, 2024 at 5:05 AM Fokko Driesprong wrote: > Hey Sung, > > T

Re: [DISCUSS] Guidelines for committing PRs

2024-08-09 Thread Micah Kornfield
As a summary, I think we are potentially at consensus. I think there are some concerns but not hard blockers: 1. Having a vote for every spec change might be too onerous (we can maybe change this policy once we have a sense of the overhead). 2. Some of the content is slightly repetitive with ot

Re: [DISCUSS] Guidelines for committing PRs

2024-08-09 Thread Walaa Eldin Moustafa
Thanks, I still have similar concerns as my original ones. There is some ambiguity in the first paragraph that might lead to inconsistencies in how different committers handle potential conflicts. Some might be overly cautious even when it’s unnecessary, while others might proceed with reviews eve

Re: [DISCUSS] Guidelines for committing PRs

2024-08-09 Thread Dmitri Bourlatchkov
I agree that a threshold on the mere number of changed files (20 in the PR) would be nice to avoid. On the other hand, I think leaving this to be a reviewer's call is fine from my perspective. Any committer could flag a change as large enough to be discussed on the dev list of go through the impro

[VOTE] Release Apache PyIceberg 0.7.1rc1

2024-08-09 Thread Sung Yun
Hi Everyone, I propose that we release the following RC as the official PyIceberg 0.7.1 release. This is a patch release due to the following bugs: * Fix correctness of applying positional deletes on Merge-On-Read tables * Fix overwrite when f

Re: [VOTE] Release Apache PyIceberg 0.7.1rc1

2024-08-09 Thread Kevin Liu
+1 (non-binding) Verified signatures/checksums/licenses. Ran unit and integration tests. Sidenote, the new Verifying a release instructions work like a charm! On Fri, Aug 9, 2024 at 12:30 PM Sung Yun wrote: > Hi Everyone, > > I propose that we rel

Re: [VOTE] Release Apache PyIceberg 0.7.1rc1

2024-08-09 Thread André Luis Anastácio
- validated signatures and checksums - checked license - ran tests and test-coverage with Python 3.9.12 +1 (non-binding) André Anastácio On Friday, August 9th, 2024 at 4:30 PM, Sung Yun wrote: > Hi Everyone, > > I propose that we release the following RC as the official PyIceberg 0.7.1 > rel

Re: [VOTE] Release Apache PyIceberg 0.7.1rc1

2024-08-09 Thread Chinmay Bhat
+1 (non-binding) - Verified signatures, checksums, license - Ran unit test and test-coverage with Python 3.9.19 Thank you for the hard work! Best, Chinmay On Sat, Aug 10, 2024 at 2:15 AM André Luis Anastácio wrote: > >- validated signatures and checksums > > >- checked license > > >

Re: [DISCUSS] Guidelines for committing PRs

2024-08-09 Thread Micah Kornfield
Thank you for the continued feedback. Thank you for the feedback. I'd like to try to shape this conversation from a different perspective. My attempt here was to capture norms that I believe the community has either already agreed on or are reasonable assumptions from an ASF perspective. With