Re: Addressing security questions in the Iceberg REST specification

Thanks JB, I do feel like the discussion around OAuth2, SigV4, etc. is a big enough topic that we wouldn't want to bundle it with other proposed changes. I think the discussion around both what is included in the spec and what the reference implementations will be for each of these protocols

Re: Addressing security questions in the Iceberg REST specification

I feel there's general openness to removing the specific OAuth2 portions of the REST Spec as they're largely duplicative of what's covered in the OAuth2 RFC. However, I do think we need a more complete discussion around client reference implementation and I would be opposed to making any changes

Re: Materialized Views: Next Steps

h6jErpGYY/edit?pli=1#heading=h.rbxigxsh4rfw > > Thanks, > Walaa. > > > On Mon, May 20, 2024 at 11:14 AM Daniel Weeks wrote: > >> I know I'm coming in late here, but I'm still working through all the >> prior discussion. Here are my thoughts so far: >> >

Re: Materialized Views: Next Steps

I know I'm coming in late here, but I'm still working through all the prior discussion. Here are my thoughts so far: I agree that Jan's doc has some really good context and we should continue from there, but we should remove discussion of options as it just creates confusion. We can reference

Re: [Proposal] Add support for Flink Maintenance in Iceberg

+1 for supporting more maintenance support in Flink Peter, just wondering if there is really any known opposition/dissenting opinions or if you're just looking for general agreement on the path forward? I would also agree with the single pipeline / post commit approach as having to configure

Re: [VOTE] Release Apache Iceberg 1.5.2 RC0

+1 (binding) Verified sigs/sums/license/build/test (Java 17) -Dan On Mon, May 6, 2024 at 11:00 AM Russell Spitzer wrote: > +1 (binding) > > Checked all the normal things > Tests > Rat > Checksum > Internal Tests > > > On May 6, 2024, at 5:35 AM, Cheng Pan wrote: > > > > +1 (non-binding) > >

Re: FlinkFileIO implementation

JB, The ResolvingFIleIO is somewhat a different issue and more complicated with a concept like FlinkFileIO because the schemes would overlap. The main issue here is around how Flink handles file system operations outside of the Iceberg space (e.g. checkpointing) and the confusion it causes for

Re: [Proposal] Add support for Materialized Views in Iceberg

+1 as well for separate objects. I think Netflix has proven this model works well. Exposure of the storage table can be handled either through naming convention or be hidden by the catalog, but that's more of an implementation detail. -Dan On Mon, Apr 22, 2024 at 3:00 PM Ryan Blue wrote: >

Re: [VOTE] Release Apache Iceberg 1.5.1 RC0

+1 (binding) Verified sigs/sums/license/build/test (Java 8) -Dan On Fri, Apr 19, 2024 at 12:23 AM Eduard Tudenhoefner wrote: > +1 (non-binding) > > * validated checksum and signature > * checked license & ran RAT checks > * ran build and tests with JDK11 > > When verifying signatures I

Re: [VOTE] Release Apache PyIceberg 0.6.1rc3

+1 (binding) Verified sigs/sums/license/tests Also manually verified the docutil dependency issues, the hive catalog timestamptz issue and v1 metadata issue. All looks great! I also made a small docs PR to improve the verification process

Re: [VOTE] Release Apache PyIceberg 0.6.1rc2

I tried running the verification process but ran into issues resolving some of the dependencies: make install Updating dependencies Resolving dependencies... (3.1s) Package docutils (0.21.post1) not found. make: *** [install-dependencies] Error 1 I found this related issue

[DISCUSS] Apache Iceberg 1.5.1 Release

Hey everyone, I wanted to open the discussion around releasing a 1.5.1 to address two known issues and see if there are any other open issues that we might consider for a patch release. I've created a 1.5.1 milestone to track potential

Re: [VOTE] Release Apache PyIceberg 0.6.1rc1

There are two main issues with the presented arguments: 1. This isn't a bundled dependency, it is an attribution of a code snippet taken from another project 2. There is nothing in the NOTICE that would qualify as "relevant portions [to be] bubbled up" You seem to be asserting that this is both

Re: [VOTE] Release Apache PyIceberg 0.6.1rc1

+1 (binding) Verified sigs/sums/license/build/test (Python 3.11.6) All checks out, -Dan On Thu, Apr 4, 2024 at 4:39 PM Hussein Awala wrote: > +1 (non-binding) > > - Verified signatures, checksums, and license > - Tested creating and reading a non-partitioned table with the Glue catalog > > On

Re: [VOTE] Release Apache PyIceberg 0.6.1rc1

Justin, We addressed these questions with regard to LICENSE and NOTICE files in the last release. This comment explains it well, which is why the NOTICE changes were reverted. The ASF recommendation

Re: Materialized view integration with REST spec

I don't think we're in a position to open a vote (or maybe there's a misunderstanding of what the vote is set out to achieve). We need to continue the discussion until there is a general consensus on the direction we want to go (not on what options are available). The vote is a confirmation of

Re: [PROPOSAL] Improvement on our PR flows

an open issue until someone gets around > >>> to removing it. > >>> > >>> We can link to https://www.apache.org/foundation/voting.html. > >>> > >>> Regards > >>> JB > >>> > >>> On Tue, Mar 12, 2024 at 2:21 AM Renjie Liu &g

Re: [PROPOSAL] Improvement on our PR flows

Hi, Daniel: > > Thanks for this summary. > > I think one thing missing is that do we need a vote for the proposal to be > accepted or rejected? If required, what should the voting process be? > > On Tue, Mar 12, 2024 at 9:04 AM Daniel Weeks wrote: > >> Hey everyone, I syn

Re: [PROPOSAL] Improvement on our PR flows

Hey everyone, I synced up with JB about the proposal process and wanted to see if we could make some initial progress. Based on some of the earlier discussions, we want to leverage as much of the informal process as possible, but improve discoverability and a little structure. This probably

Re: [VOTE] Release Apache Iceberg 1.5.0 RC6

+1 (binding) Verified sigs/sums/license/build/tests (Java 17) -Dan On Thu, Mar 7, 2024 at 2:10 PM Hussein Awala wrote: > +1 (non-binding) > - checked checksum and signature > - built from source with jdk11 > - tested read and write with Spark 3.5.1 and Glue catalog > > All looks good > > On

Re: New committer: Bryan Keller

Congratulations Bryan! Very well deserved. -Dan On Wed, Mar 6, 2024, 3:14 AM Péter Váry wrote: > Congratulations Bryan! > > Yufei Gu ezt írta (időpont: 2024. márc. 5., K, > 20:19): > >> Congrats, Bryan! >> >> Yufei >> >> >> On Tue, Mar 5, 2024 at 10:37 AM Ryan Blue wrote: >> >>>

Re: [VOTE] Release Apache Iceberg 1.5.0 RC4

+1 (binding) Verified sigs/sums/licenses/build/test (Java 17) One thing I noticed while testing views is that there is a discrepancy between the spark catalog behavior of SHOW TABLES and what I see using an Iceberg catalog (jdbc or REST). The "SHOW TABLES" command in spark catalog shows both

Re: Materialized view integration with REST spec

I feel I've been most vocal about pushing back against options 2+ (or Ryan's categories of combined table/view, or new metadata type), so I'll try to expand on my reasoning. I understand the appeal of creating a design where we encapsulate the view/storage from both a structural and performance

Re: Inconsistency between REST spec and table/view spec

g table/view. More extremely, it might be > a totally different kind of table that is only surfaced through the REST > models. > > -Jack > > On Thu, Feb 29, 2024 at 2:13 PM Daniel Weeks > wrote: > >> > In that case are tables in a REST-compliant catal

Re: Inconsistency between REST spec and table/view spec

talog choices. Storing the metadata JSON in non-open ways >>> can make users lives harder for trying out new catalogs since now the >>> metadata would be stored in their own way, and the users will have a harder >>> time accessing their own data. >>> >>>

Re: Inconsistency between REST spec and table/view spec

the minimum would be to have JSON metadata exposed >> by the REST Spec. >> >> @Jack, short term I'm in favor of your proposal, long term, I propose to >> participate on the Catalog RFC (REST Spec). WDYT ? >> >> Thanks ! >> Regards >> JB >> >> >

Re: Inconsistency between REST spec and table/view spec

Hey Jack, I'm not sure I agree with the framing of this argument. The REST Spec defines a protocol, not an implementation. The implementation of the spec can either be compliant or not. So a REST Implementation that adheres to all the requirements (atomic location swap, json representation,

Re: [VOTE] Release Apache Iceberg 1.5.0 RC3

+1 (binding) Verified sigs/sums/license/build/test (Java 17) I also did manual verification of view features using jdbc catalog (postgresql). -Dan On Thu, Feb 22, 2024 at 6:38 AM Jean-Baptiste Onofré wrote: > Correction, my vote is non-binding > > Regards > JB > > On Thu, Feb 22, 2024 at

Re: Materialized view integration with REST spec

is the right way to go, then we can debate the other issues, > and I think the next issue to reach consensus should be "Should the storage > table be registered in the catalog?". > > What do we think? > > -Jack > > > > > On Mon, Feb 19, 2024 at 11:32 AM Dani

Re: Materialized view integration with REST spec

Jack, I think we should consider either allowing the storage table to be fully exposed/addressable via the catalog or allow access via namespacing like with metadata tables. E.g. ..., which would allow for full access to the underlying table. For other engines to interact with the storage table

Re: [VOTE] Release Apache PyIceberg 0.6.0rc6

+1 (binding) Verified sigs/sums/license/tests (python 3.11) Also ran local tests against Hive and REST catalogs using appends/overwrites. -Dan On Sun, Feb 18, 2024 at 1:37 PM Ryan Blue wrote: > +1 (binding) > > * Checked checksum, signature, recent license changes > * Built and tested in

Re: [VOTE] Release Apache Iceberg Rust 0.2.0 RC1

+1 (binding) checked sigs/sums/license/build/tests A couple things I noticed that might make the verification process go smoother: 1. I didn't find any docs on how to verify a release (just docs on how to run a release). This would be really helpful so that we know what the expected setup and

Re: Deprecate DynamodbCatalog

+1 as well for deprecation On Fri, Feb 16, 2024 at 1:08 AM Jean-Baptiste Onofré wrote: > Perfect ! Thanks ! > > Regards > JB > > On Thu, Feb 15, 2024 at 7:18 PM Jack Ye wrote: > > > > Thanks for the feedback JB! Yes, I was originally intended to use this > thread to collect any concern of us

Re: [VOTE] Release Apache PyIceberg 0.6.0rc4

I think Fokko will need to weigh in on the avro usage. However, I don't think the notice for thrift or hive needs to be included. The license file states that the project uses the thrift definitions, but it does not include them in the project or dependencies. There are no direct artifacts from

Re: [VOTE] Release Apache PyIceberg 0.6.0rc4

Justin, Can you please clarify your comment about the NOTICE file? You said content is missing from the notice file, but this project does not bundle anything external that would qualify to my knowledge. The project dependencies are not included in the distribution. They are installed by the

Re: [VOTE] Release Apache PyIceberg 0.6.0rc4

-1 Unfortunately we found that the Hive catalog wasn't properly locking on table updates. I feel that since a major aspect of this release is write support, we shouldn't introduce that feature in an unsafe way. We already have a fix on main, so it shouldn't hold up moving forward with another

Re: Proposal for REST APIs for Iceberg table scans

I agree with the opaque tokens. However, I'm concerned we're overloading the endpoint two perform two distinctly different operations: distribute a plan and scan a plan. Changing the task-type then changes the behavior and the result. I feel it would be more straightforward to separate the

Re: [DISCUSS] Change iceberg-rust CI Settings to only require approval for new github users

I agree with this change. The defaults are not very community friendly and make contributing hard. -Dan On Wed, Jan 31, 2024 at 6:01 AM Xuanwo wrote: > Hello, everyone > > I'm starting this thread to discuss the possibility of changing the CI > settings for > iceberg-rust to only require

Re: [DISCUSS] iceberg-rust 0.2.0 release

+1 for 0.2.0 release as well. Really excited about the progress here. -Dan On Wed, Jan 31, 2024 at 9:36 AM Fokko Driesprong wrote: > I'm all for the 0.2.0 release. Kudos to all the work so far. While the > functionality is limited today, a lot of things are already in progress and > it looks

Re: [DISCUSS] Release new Iceberg docs site in the main repository

+1 I'm all for moving forward with this and fixing issues quickly as they're uncovered with smaller PRs. Thanks Bits! On Fri, Jan 26, 2024, 2:45 PM Ryan Blue wrote: > +1 > > On Fri, Jan 26, 2024 at 2:40 PM Brian Olsen > wrote: > >> Hey everyone, >> >> As discussed during the community sync,

Re: [DISCUSS] PyIceberg 0.6.0 release

I'm also strongly in favor of getting this release out even with the limitations as it's still a huge step forward and we can build incrementally on the write support. Incredible work everyone, I'm really excited about the progress here. -Dan On Fri, Jan 26, 2024 at 11:16 AM Fokko Driesprong

Re: [ANNOUNCE] New committer: Honah J.

Congratulations Honah! Great work on pyiceberg. I'm really excited about where that effort is headed. -Dan On Sun, Jan 14, 2024, 6:45 PM OpenInx wrote: > Congrats, Honah ! > > On Sun, Jan 14, 2024 at 1:25 AM Jun H. wrote: > >> Congratulations! >> >> On Jan 12, 2024, at 10:12 PM, Péter Váry

Re: Column-Level Key-Value Properties (Tags) in Iceberg

log) (I don't say this documentation should be in > Iceberg, but engine "providers" would need to clearly state the > supported features). > > Regards > JB > > On Mon, Jan 8, 2024 at 6:33 AM Daniel Weeks wrote: > > > > The main risk I see is that this adds compl

Re: Column-Level Key-Value Properties (Tags) in Iceberg

o minimize inconsistency in this domain, or (2) > Letting Iceberg users come up with custom, disparate, and potentially > inconsistent solutions. What do you all think? > > Thanks, > Walaa. > > On Thu, Jan 4, 2024 at 11:14 AM Daniel Weeks wrote: > >> I not op

Re: Column-Level Key-Value Properties (Tags) in Iceberg

I not opposed to the idea of adding column-level properties with a few considerations: 1. We shouldn't explicitly tie it to a particular use case like data governance. You may be able leverage this for those capabilities, but adding anything use case specific gets into some really

Re: [VOTE] Release Apache Iceberg 1.4.3 RC0

+1 (binding) Verified sigs/sums/license/build/tests Everything passed cleanly, -Dan On Thu, Dec 21, 2023 at 7:53 AM Jean-Baptiste Onofré wrote: > Hi Everyone, > > I propose that we release the following RC as the official Apache > Iceberg 1.4.3 release. > > The commit ID is

Re: Pagination for List APIs in the REST spec

cing a >>> numeric start index. >>> >>> In addition to the start index approach, another potential simple way to >>> implement the continuation token is to use the last item name, when the >>> listing is guaranteed to be in lexicographic o

Re: [DISCUSS] Apache Iceberg 1.4.3

+1 on getting this out as soon as possible On Tue, Dec 19, 2023 at 5:16 AM Jean-Baptiste Onofré wrote: > Hi Eduard, > > It's aligned with what we discussed. > +1 to cut 1.4.3 with #9227 included. > > I'm still volunteering to manage this release. > > By the way, I proposed this PR for website:

Re: Pagination for List APIs in the REST spec

I agree that we want to include this feature and I raised similar concerns to what Micah already presented in talking with Ryan. For backward compatibility, just adding a start and limit implies a deterministic order, which is not a current requirement of the REST spec. Also, we need to consider

Re: Iceberg Logo Fix and Iceberg Swag Shop

+1 On Wed, Dec 6, 2023, 9:35 AM Ryan Blue wrote: > +1 > > On Wed, Dec 6, 2023 at 9:05 AM Russell Spitzer > wrote: > >> Ah got it! For some reason I kept looking for a circle, but in the link >> you sent I can see the obvious polygon that is missing. >> >> I'm +1 on switching the image to the

Re: [VOTE] Release Apache Iceberg 1.4.2 RC0

+1 (binding) Verified sigs/sums/license/build/test (Java 11) -Dan On Sat, Oct 28, 2023 at 10:56 PM Jean-Baptiste Onofré wrote: > +1 (non binding) > > I checked: > - hash and signature are good > - ASF headers are still missing on some files (.baseline, etc): it has > been fixed on main but

Re: [VOTE] Release Apache PyIceberg 0.5.1 RC2

+1 (binding) Verified sigs/sums/license/install/test (python 3.10) Ran extensive filter tests and everything worked as expected with Arrow/Pandas/DuckDB. -Dan On Fri, Oct 27, 2023 at 3:02 PM Hussein Awala wrote: > +1 (non-binding) I ran the example notebooks and tested some queries > with

Re: Feedback on Iceberg Materialized View Spec

an, let's do that. > > Apologies. > > Regards > JB > > On Thu, Oct 26, 2023 at 8:40 PM Brian Olsen > wrote: > > > > Agreed, apologies to Jan :). JB, let's discuss this at the sync this > Wed, and after that we can create a new thread if needed. > > &

Re: Feedback on Iceberg Materialized View Spec

JB and Brian, I think we should probably move this discussion to a discuss thread specifically for the topics you want to address. We've had a few instances now where the original intent of the thread is redirected to talk about other subjects. I don't feel this is a good approach because,

Re: [VOTE] Release Apache PyIceberg 0.5.1 (RC1)

pliant (currently appears to just be evaluating to "starts with"). -Dan On Fri, Oct 20, 2023 at 6:15 PM Daniel Weeks wrote: > Fokko, I think I found a similar filter problems while experimenting: > > Using a filter like: t.scan().filter("location_id in (1,2,3)").to_ar

Re: [VOTE] Release Apache PyIceberg 0.5.1 (RC1)

Fokko, I think I found a similar filter problems while experimenting: Using a filter like: t.scan().filter("location_id in (1,2,3)").to_arrow() appears to filter correctly. However, a "like" query silently filters everything out: t.scan().filter("location_id in (1,2,3) and zone_name like

Re: [VOTE] Release Apache Iceberg 1.4.1 RC0

+1 (binding) Verified sigs/sums/license/build/test (Java 11) -Dan On Wed, Oct 18, 2023 at 7:30 AM Xuanwo wrote: > -1 (non-binding) > > - checksum and signature is good > > - the following files not have license > - .baseline/idea/intellij-java-palantir-style.xml > -

Re: [PROPOSAL] Regular release pace & some post release actions

I would agree with Fokko here. We want flexibility with releases and tracking to specific dates on the website just lends to unnecessary process. We also tend to track the release progress using github milestones especially as we get closer to the release date, which provides more context.

Re: [DISCUSSION] Rename master branch as main for the main repository

+1 On Wed, Oct 4, 2023, 3:08 PM Julien Le Dem wrote: > +1 > > On Mon, Oct 2, 2023 at 11:09 PM Fokko Driesprong wrote: > >> Big +1! >> >> Thanks for raising this JB! >> >> Kind regards, >> Fokko >> >> Op di 3 okt 2023 om 07:56 schreef Jean-Baptiste Onofré : >> >>> Thanks all for your feedback.

Re: [VOTE] Release Apache Iceberg 1.4.0 RC2

+1 (binding) Verified sigs/sums/license/build/test Using Java 17 I had failures in Flink tests (seems isolated to the Flink test framework, so not a blocker): TestIcebergSourceFailover > testBoundedWithTaskManagerFailover FAILED java.lang.IllegalAccessError: class

Re: Migration of PyIceberg to iceberg-python repository

+1 to relocate with history. On Sat, Sep 30, 2023, 10:24 AM Brian Olsen wrote: > This shouldn’t be too hard and can likely be a nightly build that occurs > with each client repository. > > We’re already planning on doing the documentation using git submodule to > pull all the documentation

Re: [VOTE] Release Apache PyIceberg 0.5.0 RC3

+1 (binding) Verified sigs/sums/license/tests Also tested some schema evolution and various other local tests and everything worked great. -Dan On Mon, Sep 18, 2023 at 8:15 AM Ryan Blue wrote: > Changing my vote to +1. Thanks for fixing the checksum, Fokko! > > On Mon, Sep 18, 2023 at 8:04 

Re: [DISCUSS] Include Spark 3.5 support in 1.4?

I'm in favor of just continuing forward with getting all of the open/identified issues in for 1.4 and then seeing where the Spark release process is before cutting the release. I would agree it's worth getting Spark 3.5 support as long as it doesn't drag on too long. We can always cut a 1.5 that

Re: [VOTE] Release Apache Iceberg 1.3.1 RC1

+1 (binding) Validated license/sigs/sums/build/test. (Had the same problem with some of the S3 containerized tests as 1.3.0) -Dan On Wed, Jul 19, 2023 at 9:29 AM Eduard Tudenhoefner wrote: > +1 (non-binding) > > * validated checksum and signature > * checked license docs & ran RAT checks >

Re: [VOTE] Release PyIceberg 0.4.0 RC2

+1 (binding) Verified sigs/sums/license/test. Also ran some basic tests with row filtering and positional deletes. -Dan On Tue, Jun 27, 2023 at 10:58 PM Jack Ye wrote: > +1 (binding) > > Verified checksum, signature, license, test, test-s3. > > Ran basic checks for Glue catalog, also

Re: [VOTE] Release PyIceberg 0.4.0 RC1

I ran into an issue with the row filtering: t.scan(row_filter="location_id > 1").to_pandas() File ~/workspace/apache/releases/pyiceberg/0.4.0-rc1/pyiceberg-0.4.0/pyiceberg/schema.py:183, in Schema.find_field(self, name_or_id, case_sensitive) 180 field_id =

Re: [DISCUSS] Switch to JDK 11 for releases?

I believe that Hive support still requires java 8 -Dan On Fri, Apr 21, 2023 at 5:02 PM Anton Okolnychyi wrote: > Sorry, I wasn’t clear that I also imply dropping JDK 8 (unless there is a > good reason to keep it?). > > - Anton > > On Apr 21, 2023, at 4:59

[ANNOUNCE] Apache Iceberg release 1.2.1

I'm pleased to announce the release of Apache Iceberg 1.2.1! Apache Iceberg is an open table format for huge analytic datasets. Iceberg delivers high query performance for tables with tens of petabytes of data, along with atomic commits, concurrent writes, and SQL-compatible table evolution.

Re: [VOTE] Release Apache Iceberg 1.2.1 RC2

>> >> Checked signature, checksum, licenses, built the project in Java 8 >> >> On Mon, Apr 10, 2023 at 1:58 PM Daniel Weeks wrote: >> >>> +1 (binding) >>> >>> Verified sigs/sums/build/test >>> Also ran through some local testing with Ja

Re: [VOTE] Release Apache Iceberg 1.2.1 RC2

ature >> Verified checksum >> Verified License >> Built and ran tests >> Ran simple queries on spark 3.3. >> >> Thanks Dan for the release, >> Szehon >> >> On Thu, Apr 6, 2023 at 12:04 PM Daniel Weeks wrote: >> >>&g

[VOTE] Release Apache Iceberg 1.2.1 RC2

Hi Everyone, I propose that we release the following RC as the official Apache Iceberg 1.2.1 release. The commit ID is 4e2cdccd7453603af42a090fc5530f2bd20cf1be * This corresponds to the tag: apache-iceberg-1.2.1-rc2 * https://github.com/apache/iceberg/commits/apache-iceberg-1.2.1-rc2 *

Re: [VOTE] Release Apache Iceberg 1.2.1 RC1

One issue was discovered while testing this release, so this vote is cancelled and we'll be following up with a new RC. Thanks everyone On Wed, Apr 5, 2023 at 5:45 PM Daniel Weeks wrote: > Hi Everyone, > > I propose that we release the following RC as the official Apache Iceber

[VOTE] Release Apache Iceberg 1.2.1 RC1

Hi Everyone, I propose that we release the following RC as the official Apache Iceberg 1.2.1 release. The commit ID is bcb4f35e15aeaf8f113c7fe8fac03f551a51a35e * This corresponds to the tag: apache-iceberg-1.2.1-rc1 * https://github.com/apache/iceberg/commits/apache-iceberg-1.2.1-rc1 *

Re: [VOTE] Release Apache Iceberg 1.2.1 RC0

Daniel Weeks wrote: > It appears that the original convenience binary artifact publish to Nexus > was incomplete. > > The updated Maven repository URL is: > https://repository.apache.org/content/repositories/orgapacheiceberg-1123/ > > On Tue, Apr 4, 2023 at 3:29 PM Daniel

Re: [VOTE] Release Apache Iceberg 1.2.1 RC0

It appears that the original convenience binary artifact publish to Nexus was incomplete. The updated Maven repository URL is: https://repository.apache.org/content/repositories/orgapacheiceberg-1123/ On Tue, Apr 4, 2023 at 3:29 PM Daniel Weeks wrote: > Hi Everyone, > > I propos

[VOTE] Release Apache Iceberg 1.2.1 RC0

Hi Everyone, I propose that we release the following RC as the official Apache Iceberg 1.2.1 release. The commit ID is 3b47c49c4c9270e746938e07cf9edda3ae02a86d * This corresponds to the tag: apache-iceberg-1.2.1-rc0 * https://github.com/apache/iceberg/commits/apache-iceberg-1.2.1-rc0 *

Re: [DISCUSS] Apache Iceberg Release 1.2.1

buting to the discussion! -Dan On Tue, Apr 4, 2023 at 8:50 AM Daniel Weeks wrote: > Thanks Amogh, we've added #7273 to the milestone. > > I think we're addressed all the issues identified in the milestone > <https://github.com/apache/iceberg/milestone/31>. > > Unless anyone else has a

Re: [DISCUSS] Apache Iceberg Release 1.2.1

gt; >>> >>> >>> I think we would want to include >>> https://github.com/apache/iceberg/pull/7273/files in a 1.2.1 release. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Amogh Jahagirdar >>

Re: [DISCUSS] Apache Iceberg Release 1.2.1

Daniel, > > Thanks for bringing up this discussion, I suppose the following PR should > be included in 1.2.1 > > https://github.com/apache/iceberg/pull/7153 > > Thanks, > Cheng Pan > > > On Apr 3, 2023 at 12:08:26, Daniel Weeks wrote: > >> Hey Iceberg Community

[DISCUSS] Apache Iceberg Release 1.2.1

Hey Iceberg Community, I wanted to start a discussion around a patch release for 1.2.0 after a number of small issues have been found that impact features of the current release. I've created a milestone to track issues related to the patch

Re: [DISCUSS] Iceberg Community Guidelines

+1 for the guidelines. >>> >>> I also like the idea of a jobs channel! >>> >>> On Fri, Mar 17, 2023 at 7:18 PM wrote: >>> >>>> Looks good to me , although for recruiting I think maybe we should have >>>> a dedicated jobs chan

Re: [VOTE] Release Apache Iceberg 1.2.0 RC1

+1 (binding) verified license/sigs/sums/build/test Also verified sigv4 and snapshot ref-only loading. Ran with Jdk17 -Dan On Thu, Mar 16, 2023 at 10:46 PM Jahagirdar, Amogh wrote: > +1 (non-binding) > > 1. Verified checksum and signature > > 2. Verified license docs and ran RAT checks > >

[DISCUSS] Iceberg Community Guidelines

Hey everyone, With the increasing level of activity in the Iceberg channels, I feel now is a good opportunity to establish some guidelines around how individuals and those with corporate interests engage with the community. We discussed this at the most recent Iceberg community sync, but want to

Re: [DISCUSS] Removing python_legacy from the repo

+1 for removal On Tue, Feb 21, 2023, 7:38 AM Jack Ye wrote: > +1 for removing it! > > Thanks, > Jack Ye > > On Fri, Feb 17, 2023 at 4:18 PM Steve Zhang > wrote: > >> Thank you Fokko and Ryan for your great work to reach feature parity. >> pyiceberg is the way to go! >> >> Thanks, >> Steve

Re: [VOTE] Release Apache PyIceberg 0.3.0

+1 (binding) Verified sig/sums/license/test (including s3) Ran through some manual tests using the REST Catalog and everything worked as expected. Looks great, -Dan On Sun, Feb 5, 2023 at 10:08 AM Jack Ye wrote: > +1 (binding) > > Verified signature, checksum, RAT > > Ran unit and

Re: [VOTE] Release Apache PyIceberg 0.3.0

+0 Verified sigs and sums, but ran into the following issues running through the verification steps: *Ran into the following error verifying the licenses. Touching the file fixed the issue.* $ ./dev/check-license Attempting to fetch rat Exception in thread "main" java.io.FileNotFoundException:

Re: [VOTE] Release Apache PyIceberg 0.2.1

+1 (binding) Verified: - sigs/sums/license/tests - removal of hard dependency on pyarrow I don't believe the following should block this release unless they were introduced in this patch version, but I ran into the following: - pyparsing was not installed during 'make install' and tests

Re: [VOTE] Release Apache PyIceberg 0.2.0

+1 (binding) I verified: - sigs, sums, licenses, tests I tested: - REST Catalog implementation - creating/loading/renaming/dropping tables - creating/removing namespace properties - loading table to arrow dataframe via scan (and pandas via arrow) - loading table to duckdb I had one

Re: [VOTE] Release Apache Iceberg 1.1.0 RC4

+1 (binding) Verified sigs/sums/licenses/build/test Built and tested with JDK 8 -Dan On Fri, Nov 25, 2022 at 5:58 PM leilei hu wrote: > +1(non-binding) > verified(java 8): > > - Create table using HiveCatalog and HadoopCatalog > - Spark Structured Streaming with Spark 3.2.1 > - Spark query

Re: [DISCUSS] Semantic Versioning Guarantees post 1.0

of the codebase, so I think the long term plan is to fold them into the iceberg-core module so they should be treated similarly. I'll put together a PR to update the contributing section to include information about semantic versioning. -Dan On Fri, Sep 30, 2022 at 10:16 AM Daniel Weeks wrote: > Yu

Re: [VOTE] Release Apache Iceberg 1.0.0 RC0

+1 (binding) Verified sigs/sums/license/build/test (java 8) Everything checks out, -Dan On Mon, Oct 10, 2022 at 3:25 PM Steven Wu wrote: > Never mind. Missed the information that this 1.0.0 is based on the latest > 0.14.1 release, which doesn't contain the PR 5318. I thought it was based > on

Re: [DISCUSS] Semantic Versioning Guarantees post 1.0

ajorVersionCompatibleAPI. > > Best, > > Yufei > > `This is not a contribution` > > > On Thu, Sep 29, 2022 at 1:06 PM Ryan Blue wrote: > >> +1 to the approach outlined here. Thanks, Dan! >> >> On Wed, Sep 28, 2022 at 4:18 PM Daniel Weeks wrote: >> >>> Hey

Re: [VOTE] Release Apache PyIceberg 0.1.0 RC2

+1 I checked sigs/sums/license/tests. I ran through the CLI commands with REST Catalog and a few with Hive Metastore. Minor issues (non-blockers): - Miss configuration with uri / credentials often resulted in confusing errors (asking to set the fields which were already supplied). - I wasn't

[DISCUSS] Semantic Versioning Guarantees post 1.0

Hey Iceberg Community, I wanted to raise a discussion thread with respect to how to handle semantic versioning and deprecations so that we can document the expectations for changes to the baseline going forward. The goal is to clarify/formalize for users, contributors, and reviewers the

Re: [VOTE] Release Apache Iceberg 0.14.1 RC3

+1 (binding) Verified: sigs, sums, license, build and test (java 8) -Dan On Sat, Sep 3, 2022 at 6:17 PM Ryan Blue wrote: > +1 (binding) > >- Checked signature and checksum >- Ran RAT checks >- Tested with Java 11 > > Ryan > > On Sat, Sep 3, 2022 at 5:41 PM Ryan Blue wrote: > >>

Re: Welcome Yufei Gu as a committer

Congrats! On Thu, Aug 25, 2022, 7:41 PM Reo Lei wrote: > Congratulations~  > > Russell Spitzer 于2022年8月26日周五 09:01写道： > >> Congrats! >> >> Sent from my iPad >> >> > On Aug 25, 2022, at 6:20 PM, Anton Okolnychyi >> wrote: >> > >> > I’d like to welcome Yufei Gu as a committer to the

Re: [VOTE] Release Apache Iceberg 0.14.0 RC1

+1 (Binding) I checked sigs/sums/build/test and verified with some local tests. I did run into some minor issues that I wouldn't consider release blocking: - Some transient test failures - I was able to reproduce the S3FileIO test failure others reported, but it was transient - I ran into

Re: [VOTE] Adopt Puffin format as a file format for statistics and indexes

+1 as well. Excited about the progress here. -Dan On Thu, Jun 9, 2022, 6:25 PM Junjie Chen wrote: > +1, really nice! Indexes are coming! > > On Fri, Jun 10, 2022 at 8:04 AM Szehon Ho wrote: > >> +1, it's an exciting step for Iceberg, look forward to all the new >> statistics and secondary

Re: [VOTE] Release Apache Iceberg 0.13.2 RC1

+1 (binding) verified sigs/sums/license/build/tests As for the detached commit, I believe I commented on this in a prior release and the parent commit is the head of the 0.13.x branch and the detached commit is just the version bump, so I'm ok with it, but it sure would be nice if that wasn't

Re: Welcome Szehon Ho as a committer!

Congratulations! -Dan On Sun, Mar 13, 2022, 12:14 AM Reo Lei wrote: > Congratulations Szehon! > > BR, > Reo > > Rajarshi Sarkar 于2022年3月12日周六 16:45写道： > >> Congratulations, Szehon! >> >> Regards, >> Rajarshi Sarkar >> >> On Sat, Mar 12, 2022 at 9:51 AM Arthur Wiedmer wrote: >> >>>

  1   2   >