Hi Ed,
I like option 2, it simplifies the parameterized support.
Just my $0.01
Regards
JB
On Thu, Dec 7, 2023 at 5:16 PM Eduard Tudenhoefner
wrote:
> Hey everyone,
>
> a while ago we (thanks to many contributors that helped here) started
> migrating tests from JUnit4 to JUnit5. While most thi
> list regularly soon after the community sync. I have not been able to attend
> the sync recently and I haven't seen the minutes for the last two syncs. Can
> we please maintain the practice of sending the minutes and recording out?
> Thanks,
> Wing Yew
>
>
> On
+1
Regards
JB
On Wed, Dec 13, 2023 at 7:10 PM Ajantha Bhat wrote:
>
> Hi All,
>
> In our recent discussion, we deprecated Spark 3.2 support in Iceberg 1.4.0
> release
> as outlined in this thread:
> https://lists.apache.org/thread/zw1blng2d1bbrlcftxwmmhb2l7jxbxqx
>
> As we're gearing up for th
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:
https://github.com/apache/iceberg-docs/pull/298
Regards
JB
On Tue, Dec 19, 2023 at 8:38 AM Eduard Tudenhoefner
wrote:
No problem at all :)
Regards
JB
On Tue, Dec 19, 2023 at 8:51 AM Eduard Tudenhoefner
wrote:
>
> Sorry I forgot that this thread about 1.4.3 existed and opened a new DISCUSS
> thread to do a 1.4.3 release.
>
> On Mon, Dec 4, 2023 at 11:25 AM Jean-Baptiste Onofré
> wro
Hi all,
FYI, I'm working with Eduard to include #9230 in 1.4.3 as well.
We have updated the KEYS file with my sign/key, I'm doing a
preparation step (build, verify, etc).
Regards
JB
On Tue, Dec 19, 2023 at 8:38 AM Eduard Tudenhoefner
wrote:
>
> Hey everyone,
>
> I'd like to start a discussion
Hi all,
quick update about 1.4.3 release: we have
https://github.com/apache/iceberg/pull/9356 to backport #9354 on 1.4.x
branch.
As soon as this one is merged, the release process will start.
Stay tuned ! :)
Regards
JB
On Wed, Dec 20, 2023 at 1:34 PM 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 9a5d24fee239352021a9a73f6a4cad8ecf464f01
* This corresponds to the tag: apache-iceberg-1.4.3-rc0
* https://github.com/apache/iceberg/commits/apache-iceberg-1.4.3-rc0
*
https://g
Casting my own +1 :)
Regards
JB
On Thu, Dec 21, 2023 at 4:53 PM 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 9a5d24fee239352021a9a73f6a4cad8ecf464f01
> *
Hi,
As we are in Christmas time, I give an extra day for people to vote.
Regards
JB
On Thu, Dec 21, 2023 at 4:53 PM Jean-Baptiste Onofré wrote:
>
> Hi Everyone,
>
> I propose that we release the following RC as the official Apache
> Iceberg 1.4.3 release.
>
eep up with the weekly release cycle to stay ahead of regressions.
>
> https://github.com/trinodb/trino/pull/20159
>
> I would recommend us cutting the release as soon as possible since the
> Trino release will happen tomorrow.
>
> On Tue, Dec 26, 2023 at 11:46 AM Jean-Baptiste O
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 9a5d24fee239352021a9a73f6a4cad8ecf464f01
> * This corresponds to the tag: apache-iceberg-1.4.3-rc0
> * https:
I'm pleased to announce the release of Apache Iceberg 1.4.3!
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.
This
Hi
Happy to do help using my Apache member hat with other Iceberg committers.
Regards
JB
On Tue, Jan 2, 2024 at 3:39 PM Brian Proffitt wrote:
>
> All:
>
> If any of the committers are interested in doing this podcast, please
> let me know!
>
> BKP
>
> -- Forwarded message -
> Fr
Hi Ajantha
It sounds good to me. I would like to submit PR for views support on JDBC
Catalog. But I guess it will take time for review.
If we can wait at least a week before starting the release process it would
be great.
You will need help from a PMC member to complete some tasks.
I saw also th
t; On Wed, Dec 6, 2023 at 3:06 PM Wing Yew Poon
>>> wrote:
>>>>
>>>> The meeting minutes and a link to the recording used to be sent out to
>>>> this list regularly soon after the community sync. I have not been able to
>>>> attend the sync
ject to have the meeting minutes to be posted? The day of or the next day?
>
>
> On Wed, Jan 3, 2024 at 12:29 AM Jean-Baptiste Onofré
> wrote:
>>
>> Hi,
>>
>> Agree: we should have a list of "community meeting managers" to handle
>> the rec
Hi guys,
We have several examples where we have some kind of "stale" PRs,
either because we are waiting for a review, or we are waiting for
changes from the contributor.
We are already using two jobs around issues/PRs:
- labeler to label PRs depending of the Iceberg modules change scope
- stale
Hi
That's also the purpose of the reviewers file: having multiple
reviewers per tag.
Thanks guys for your feedback, I will move forward with the PR :)
Regards
JB
On Thu, Jan 4, 2024 at 6:38 AM Ajantha Bhat wrote:
>
> +1,
>
> Some of my PRs have been open for a long time and sometimes it doesn'
as soon as the first is merged.
>
> Bryan
>
> > On Nov 9, 2023, at 9:30 AM, Jean-Baptiste Onofré wrote:
> >
> > Hi Bryan
> >
> > I would like to follow up about kafka connect sink donation.
> >
> > If you don't mind, I would like to propose a PR
d
> so the PR is just waiting on those who might want another pass.
>
> -Bryan
>
> > On Jan 4, 2024, at 9:36 AM, Jean-Baptiste Onofré wrote:
> >
> > Hi Bryan
> >
> > I did a new pass on https://github.com/apache/iceberg/pull/8701 and it
> >
Hi Dan,
I agree: it will depend on the engine capabilities. That said, it's
similar to catalog: each catalog might have different
approaches/features/capabilities, so engines might have different
capabilities as well.
If it's an optional feature in the spec, and each engine might or
might not impl
ements, even if it does not expose a way to
> view/manipulate them. This is why scrutiny of spec changes is critical.
>
> +1 to what you said about documentation and support.
>
> -Dan
>
>
>
> On Mon, Jan 8, 2024 at 1:38 AM Jean-Baptiste Onofré wrote:
>>
>>
Congrats !
Regards
JB
Le ven. 12 janv. 2024 à 22:11, Fokko Driesprong a écrit :
> On behalf of the Iceberg PMC, I'm happy to announce that Honah has
> accepted an invitation to become a committer on Apache (Py)Iceberg.
> Welcome, and thank you for your contributions!
>
> Kind regards,
> Fokko
>
Hi
Of course I’m volunteer :)
Regards
JB
Le ven. 12 janv. 2024 à 18:47, Ryan Blue a écrit :
> Hi everyone,
>
> We've been having discussions about how to put together an Iceberg
> conference or summit for this year and one of the first steps is to put
> together a selection committee that will
Hi Jan
You are right, we quickly discussed about this during community
meeting and on the mailing list.
First, we discussed about using GitHub Discussions, but we agreed on
using GitHub Issues.
I like your proposal: creating a GitHub Issues with "Proposal:" prefix
on the title sounds good to me.
Hi Rick,
It's not possible to attach files on the mailing list. Can you please
share the logo somewhere ?
Thanks !
Regards
JB
On Mon, Jan 15, 2024 at 5:31 PM Rick Bilodeau wrote:
>
>
> Hello,
>
> I'd like to propose adopting the attached artwork as the official PyIceberg
> logomark. If it is a
Hi Rick,
Thanks ! It looks great :)
Regards
JB
On Mon, Jan 15, 2024 at 5:43 PM Rick Bilodeau wrote:
>
> The artwork is linked here.
>
> https://drive.google.com/file/d/1oV9qolfyIi5YkEvA0NJb3ipECGBdsUqX/view?usp=sharing
>
>
>
> On Mon, Jan 15, 2024 at 8:35 AM Jean-B
>> anyway since we combine logos here, so I'll do that now. I'll let you know
>> what comes out of it
>>
>> Kind regards,
>> Fokko
>>
>>
>>
>> Op ma 15 jan 2024 om 18:28 schreef Jean-Baptiste Onofré :
>>>
>>>
Hi,
I agree. I see the same adding view support on the JDBC Catalog
(https://github.com/apache/iceberg/pull/9487).
It would be a good improvement. As discussed in the Hive PR, I think
we can move forward with Iceberg 1.5.0 release including view support,
and do this improvement for 1.6.0.
I think
g.apache.org/logos. This also gives a
>>> centralized place for people to more easily consume those logos with the
>>> related licensing information.
>>>
>>> A related question, do we plan to create logos also for the other projects
>>> iceberg-rust an
Thanks Brian !
Regards
JB
On Wed, Jan 24, 2024 at 10:01 PM Brian Olsen wrote:
>
> Hey all,
>
> We have quite a bit going on this first sync post holiday. Looking forward to
> seeing the Java/Python releases (especially writes in PyIceberg) coming soon.
> The switch to the new docs is about to
Hi Justin,
I talked with Junping a couple of months ago about Gravitino. Thanks
for sharing !
Regards
JB
On Thu, Jan 25, 2024 at 12:15 AM Justin Mclean wrote:
>
> Hi,
>
> We open-sourced a new project, Gravitino, in December and have been working
> on growing the community and adding new funct
+1
Regards
JB
On Fri, Jan 26, 2024 at 11:40 PM Brian Olsen wrote:
>
> Hey everyone,
>
> As discussed during the community sync, I'd like to get a vote on moving
> forward with the documentation. I have created a PR
> (https://github.com/apache/iceberg/pull/9520) that references the changes
>
Hi guys,
If we have a few user questions on the dev mailing list, we have quite
a number on Slack.
It's completely fine but not easy to search the questions and find the
concrete answer.
As most other Apache projects do, I propose to create a user mailing
list to invite people to ask questions an
Slack threads available through the mailing
> list. Is there a slack bot you have in mind? How would the threads appear in
> the mailing list?
>
> On Tue, Jan 30, 2024 at 7:13 AM Jean-Baptiste Onofré
> wrote:
>>
>> Hi guys,
>>
>> If we have a few user question
cally
> (https://github.com/apache/iceberg/pull/9563)
>
> Also this is a last call for PRs, let me know if anything else is urgently
> needed for 1.5.0 release.
>
> - Ajantha
>
> On Wed, Jan 3, 2024 at 11:33 AM Jean-Baptiste Onofré
> wrote:
>>
>> Hi Ajantha
be able to
>> search for those Slack questions and answers on the internet. Maybe we can
>> consider a separated "slack" mailing list for that purpose.
>>
>> Best,
>> Jack Ye
>>
>> On Tue, Jan 30, 2024 at 8:16 AM Jean-Baptiste Onofré
>> w
Hey Jacob
Thanks ! As discussed during one of the last community meetings, we
should discuss/include nanosecond timestamp support in a Spec V3.
I propose to include this discussion in the next community meeting
(scheduled next week on Feb 14th).
Thanks again, I will do a pass on the PR.
Regards
Hi Jack,
If we have a very low number of users and propose they move to another
catalog, that makes sense to me.
I think we can first flag DynamodbCatalog as deprecated (providing a
message to the community and give time for users to move forward),
then we can plan a vote later to remove it.
Reg
Hi Brian,
Thanks for sharing!
Imho, "deprecating some catalogs" is a bit premature and scary as we
are talking only about DynamodbCatalog. For our users, I think it
would be better to wait for formal discussion on the mailing list (and
eventually vote) before announcing this kind of message.
Than
No problem Brian :)
Just wanted to avoid confusion for our users :)
Thanks !
Regards
JB
On Thu, Feb 15, 2024 at 2:58 PM Brian Olsen wrote:
>
> Apologies, I said this in jest, please refer to the notes and sync discussion
> for more details.
>
> On Thu, Feb 15, 2024 at 7:55 A
xt 5 days, I will go ahead to do
> that, and let the default 2 release full deprecation window apply. And I will
> revive this thread again to double check when we plan to remove it after 2
> releases.
>
> Best,
> Jack Ye
>
> On Thu, Feb 15, 2024 at 2:33 AM Jean-Baptiste
Hi Fokko,
I agree to remove Hadoop 2.7.3 and bump to 3.x for Iceberg 2.0.0.
If we want to be based on Java 11+ (17 would be good imho), we have to
check the dependencies. I'm not sure all of our dependencies support
JDK17 today.
Regards
JB
On Fri, Feb 16, 2024 at 10:09 AM Fokko Driesprong wrot
Hi Jack,
It's a good idea and it has to be pluggable.
I think we could have a TableConfigResponse and ViewConfigResponse
that could contain the policy field + key/value pair open list. The
idea is let the REST backend to deal with permission (
We would be able to extend permission this way.
Gen
Hi guys,
During the last community meeting, we started to quickly discuss Iceberg 2.0.
I was quite surprised it came during the community meeting because I
don't remember having a previous discussion (on the mailing list)
about that.
So, I would like to have to start an open discussion about our
+1 (non binding)
I checked:
- checksum and signature are correct
- ASF headers are OK
- no binary found in the source distribution
- build is OK from the source distribution
To be improved for next releases (not blocker at all):
- NOTICE file should mention dependencies and tools used (not
necess
+1 (non binding)
I checked:
- checksum and signature are correct
- ASF headers are there (not in the tsv files but not a problem)
- no binary found in the source distribution
Good improvement for next releases: update NOTICE file to mention non
ASF dependencies (listed in DEPENDENCIES.rust.tsv) w
Iceberg 1.5.0 client can't create a table against a server
> running an older Iceberg version.
>
> I'll have a fix shortly for this and will create RC1.
>
> Eduard
>
> On Mon, Feb 19, 2024 at 11:26 AM Jean-Baptiste Onofré
> wrote:
>>
>> +1 (non binding
E as brief and simple as possible, as each
> addition places a burden on downstream consumers.
>
> Do not add anything to NOTICE which is not legally required.
>
> It sounds like the content you’re talking about would be better located in
> the README instead.
>
> Ryan
>
Hi Manu
Thanks for the reminder. It sounds like a good feature and worth
discussing it :).
It was my intention to define what we plan to include (or not) in Spec
v3 / Iceberg 2.0.0 (I sent a message about that last week).
Regards
JB
On Tue, Feb 20, 2024 at 10:36 AM Manu Zhang wrote:
>
> Do we
t;> > strict about what goes into the NOTICE file to comply with ASF guidance:
>>> >
>>> > The NOTICE file is reserved for a certain subset of legally required
>>> > notifications which are not satisfied by either the text of LICENSE or
>>> >
Unfortunately, we identified an issue with Trino and JDBC catalog (see
https://github.com/apache/iceberg/issues/9764 for details).
I'm working on a fix right now (PR will be available soon).
Sorry, but we will need a RC2 :/
Regards
JB
On Tue, Feb 20, 2024 at 11:33 AM Ajantha Bhat wrote:
>
> Hi
I created https://github.com/apache/iceberg/pull/9765 to fix JDBC
Catalog schema management.
Regards
JB
On Tue, Feb 20, 2024 at 5:17 PM Jean-Baptiste Onofré wrote:
>
> Unfortunately, we identified an issue with Trino and JDBC catalog (see
> https://github.com/apache/iceberg/issues
> Ryan
>
> On Tue, Feb 20, 2024 at 1:58 AM Jean-Baptiste Onofré
> wrote:
>>
>> Hi Manu
>>
>> Thanks for the reminder. It sounds like a good feature and worth
>> discussing it :).
>>
>> It was my intention to define what we plan to include (or not
copyright headers that were relocated to
> NOTICE by the original author.
>
> Ryan
>
>
> On Tue, Feb 20, 2024 at 8:16 AM Jean-Baptiste Onofré
> wrote:
>>
>> OK, no problem, let's keep as it is if you prefer (as I said it's not
>> a blocker).
>&g
Hi Jacob
Good catch. Ryan already updated the doc: the Summit will be on
Tuesday and Wednesday (May 14th & 15th).
Regards
JB
On Wed, Feb 21, 2024 at 8:58 PM Jacob Marble wrote:
>
> The document contains conflicting dates. May 13th & 14th, or May 14th & 15th?
>
> On Tue, Feb 20, 2024 at 10:23 PM
That's a good idea. Actually, we already have the #summit channel to
have discussions around the summit.
Regards
JB
On Thu, Feb 22, 2024 at 7:16 AM Manu Zhang wrote:
>>
>> I think the event time is odd for people in Asia to attend.
>
> We can set up dedicated slack channels to collect questions
+1 (binding)
I checked:
- signatures and checksum are OK
- ASF license headers
- no binary file found in the source distribution
- LICENSE/NOTICE are OK (regarding the discussion we had :) )
- Build OK with JDK11
- Tested JdbcCatalog (with different schema version) with PostgreSQL backend
- Tested
Correction, my vote is non-binding
Regards
JB
On Thu, Feb 22, 2024 at 10:07 AM Jean-Baptiste Onofré wrote:
>
> +1 (binding)
>
> I checked:
> - signatures and checksum are OK
> - ASF license headers
> - no binary file found in the source distribution
> - LICENSE/NOTI
ksum, build, test with Java17
>>> Ran manual test with EMR 7.0 Spark 3.5 and Glue.
>>>
>>> Best,
>>> Jack Ye
>>>
>>> On Thu, Feb 22, 2024 at 7:58 PM Daniel Weeks wrote:
>>>>
>>>> +1 (binding)
>>>>
>>>&
+1 (non binding)
I checked:
- Signature and checksum are OK
- Build is OK on the source distribution
- ASF headers are present
- No binary file found in the source distribution
- Tested on iceland (sample project) + trino and also JDBC Catalog
Thanks !
Regards
JB
On Tue, Feb 27, 2024 at 1:16 PM
e have met a consensus here, I can pick up the
>>>>> deprecation of DynamoDbCatalog. I submitted a PR that marks the catalog
>>>>> as deprecated and schedules it for complete removal in two releases
>>>>> starting with 1.6.0.
>>>>>
&
g implementation.
>>>>>>
>>>>>> I think this is actually something that is lacking today in Iceberg,
>>>>>> which is an easy way for users to start an actual REST HTTP server.
>>>>>>
>>>>>> I know we have the
n to anyone who wants to participate/contribute.
Thoughts ?
Regards
JB
On Thu, Feb 29, 2024 at 11:56 AM Jean-Baptiste Onofré wrote:
>
> Hi Ajantha,
>
> Thanks for sharing your thoughts.
>
> It makes sense for Gravitino to be a TLP (after the incubation period)
> because Graviti
Hi Dan,
I agree with your statement about REST Spec is not an implement but I
strongly disagree with your statement "impl of the spec can either be
compliant or not".
The REST Catalog spec impl should be consistent with the REST Spec. That's
why a reference implementation in Iceberg would be a mu
o way to really prove that, because the REST spec does not
>> enforce it.
>>
>> JB, what do you mean by participating on the Catalog RFC? Is there already
>> an ongoing RFC?
>>
>> -Jack
>>
>>
>> On Thu, Feb 29, 2024 at 12:08 PM Jean-Baptiste
, because the REST spec does not
> enforce it.
>
> JB, what do you mean by participating on the Catalog RFC? Is there already an
> ongoing RFC?
>
> -Jack
>
>
> On Thu, Feb 29, 2024 at 12:08 PM Jean-Baptiste Onofré
> wrote:
>>
>> Hi Dan,
>>
>&
be used to wire up something like a REST
> catalog, but not provide a runtime service.
>
> Ryan
>
>
> On Thu, Feb 29, 2024 at 2:59 AM Jean-Baptiste Onofré
> wrote:
>>
>> Hi Ajantha,
>>
>> Thanks for sharing your thoughts.
>>
>> It makes
ve Iceberg a try. One of the main
> motivations for doing it this way was that it doesn't require any additional
> services. Running additional services would require having JRE/Docker/etc
> being installed and potentially also an RDBMS backend to persist the data.
>
> Kind re
c. What's more, in an enterprise iceberg rest
> catalog usually is only part of a data platform, there are many other things
> involved. In this case, I'm skeptical about the actual value of a rest
> catalog server, and a spec or a library would be more valuable.
>
> On F
> - A catalog implementation per JDBC backend. (Blue)
> - Servlet like Tomcat or Spring to run / package the service. (Blue)
>
> On Fri, Mar 1, 2024 at 2:54 AM Jean-Baptiste Onofré wrote:
>>
>> Hi Renjie,
>>
>> maybe I wasn't clear, sorry about that: the
vice. We may choose to add one in order to make it easier to move to the
>> REST client, but I'm not confident that is the right choice vs encouraging
>> other projects.
>>
>> On Fri, Mar 1, 2024 at 4:43 AM Jean-Baptiste Onofré
>> wrote:
>>>
>>>
Hi Jack
Thanks for sharing !
Let me take a look at the doc. I'm also interested in participating in
REST Spec (I started to work on a simple REST catalog impl to evaluate
some gaps).
Regards
JB
On Fri, Mar 1, 2024 at 10:34 PM Jack Ye wrote:
>
> Hi everyone,
>
> Based on the discussion that we
gt;>>>
>>>>>> - Checked checksum and signature
>>>>>> - Ran a modified version of dbt-spark to take advantage of the views,
>>>>>> and it worked like a charm! 🥳
>>>>>>
>>>>>> Cheers, Fokko
>>>>&
+1 (non binding)
- checksums and signatures are OK
- ASF headers are present
- No unexpected binary files in the source distribution
- Build OK with JDK11
- JdbcCatalog tested on Trino and Iceland
- No unexpected artifact distributed
Thanks !
Regards
JB
On Wed, Mar 6, 2024 at 12:04 AM Ajantha B
Hi Ajantha,
We will discuss that within the Selection Committee.
I think it would be great to reserve one slot (30mn) for lightning
talks (as we do at ApacheCon/CoC), meaning 6 lightning talks.
That's my personal view, I will bring this to the committee.
Regards
JB
On Thu, Mar 7, 2024 at 7:52 AM
Hi guys,
Let me ping again on this thread ;)
I think it would be great to give some visibility to the community,
especially about Spec v3 and Iceberg 2.0.0.
Any comments about Spec V2 / Iceberg 2.0.0 ?
Thanks !
Regards
JB
On Fri, Feb 16, 2024 at 4:52 PM Jean-Baptiste Onofré wrote:
>
&
big "everything 2.0"
> thread. It just doesn't seem manageable to me to cover them all at once.
> Maybe that's just me though.
>
> Ryan
>
> On Thu, Mar 7, 2024 at 7:49 AM Jean-Baptiste Onofré
> wrote:
>
>> Hi guys,
>>
>> Let me ping aga
Hi Benny
Thanks for your message. I think the idea is to "smoothly"
(implicitly) add regular table storage over a view.
The MV approach is right now in discussion, without consensus so far.
We plan to have document/meeting to discuss further.
Regards
JB
On Fri, Mar 8, 2024 at 7:18 AM Benny Chow
er
>> to either close or take action on an issue. For me, it makes sense to extend
>> this to PRs as well.
>>
>> Same as Amogh said, always feel free to ping me when either a PR or issue
>> lingering and you need some eyes on it.
>>
>> Kind regards,
>
update roadmap page on the website to have some visibility (it would
be helpful for us too :)).
Thoughts ?
Regards
JB
On Thu, Mar 7, 2024 at 7:43 PM Jean-Baptiste Onofré wrote:
>
> Hi Ryan
>
> Yeah I agree to separate discussions on each topic. Actually that was my
> intention ;)
Hi folks,
Just a quick reminder when doing a release: we should clean up
dist.apache.org areas.
The artifacts from dist.apache.org release are automatically copied on
archive.apache.org. So we should have only the latest release
artifacts here https://dist.apache.org/repos/dist/release/iceberg/
nitial template and docs.
>>
>> I think we want to introduce this with as little overhead as possible.
>> Please follow up with questions/comments so we can close this out.
>>
>> Thanks,
>> Dan
>>
>>
>> On Sun, Mar 10, 2024 at 11:30 PM Jean-Bapt
Hi
I agree with the naming comments from Fokko.
About releases, we should only include releases since the last report
(quarter). However, if needed, we can include older releases with a
note like "forget in last report".
The community health is great, thanks for that.
Thanks Ryan for the report
> want to get into 2.0.0. I'm open to creating a Discussion issue if more
> people think this is a good idea (typically this was discussed on the mailing
> list within the ASF context).
>
> Thanks,
> Fokko
>
> Op ma 11 mrt 2024 om 07:34 schreef Jean-Baptiste Onofré :
>
any questions or concerns from the PMC before adopting
> this?
>
> Kind regards,
> Fokko Driesprong
>
> Op wo 13 mrt 2024 om 13:17 schreef Renjie Liu :
>>
>> Hi, JB:
>>
>> Your proposal looks great to me. We should definitely have a vote for a
>> p
on that)
>
> Thanks,
> -Dan
>
>
>
> On Wed, Mar 20, 2024 at 10:01 AM Jean-Baptiste Onofré
> wrote:
>>
>> Hi Fokko
>>
>> I think combining Dan's proposal about "proposal process" and this
>> proposal about "PR flows"
Hi folks
Now that we have the proposal process "merged", I will create the PR
about reviewers and update stale job.
I should have the PR tomorrow for review.
Thanks !
Regards
JB
On Thu, Mar 21, 2024 at 9:55 AM Jean-Baptiste Onofré wrote:
>
> Hi Dan
>
> Yes, I saw you m
Hi Renjie,
We discussed the MV proposal, without yet reaching any conclusion.
I propose:
- to use the "new" proposal process in place (creating an GH issue with
proposal flag, with link to the document)
- use the document and/or GH issue to add comments
- finalize the document heading to a vote (
ied. In my opinion, having
>> multiple module owners would enable developers to seek feedback more
>> efficiently.
>>
>> - Ajantha
>>
>> On Thu, Mar 21, 2024 at 11:11 PM Jean-Baptiste Onofré
>> wrote:
>>>
>>> Hi folks
>>>
>>
Hi
It looks good to me, thanks !
Regards
JB
On Tue, Mar 26, 2024 at 6:25 PM Honah J. wrote:
>
> Hi everyone,
>
> This week we've discovered a serious bug that causes pyiceberg fail to create
> version 1 table with non-empty partition-spec and sort-order. According to
> the discussion in today
mailing list.
Regards
JB
On Wed, Mar 27, 2024 at 6:57 AM Jean-Baptiste Onofré wrote:
>
> Adding a group of people as reviewers doesn't block others from help
> and review (and it doesn't change what we do now). I don't see how
> it's different to today, just having
It sounds good. I would also propose to use the "proposal process":
creating a github issue with the "proposal" tag and link the document
there in a comment.
Regards
JB
On Tue, Mar 26, 2024 at 3:05 PM Walaa Eldin Moustafa
wrote:
>
> Thanks Jan! To avoid spreading discussions on multiple places,
n to discuss the updates. (doc link here for convenience).
>
> Thanks,
> Walaa.
>
>
> On Tue, Mar 26, 2024 at 11:37 PM Jean-Baptiste Onofré
> wrote:
>>
>> It sounds good. I would also propose to use the "proposal process":
>> creating a g
Yes, correct, thanks Manu for pointing it out.
Thanks !
Regards
JB
On Thu, Mar 28, 2024 at 9:55 AM Manu Zhang wrote:
>
> I think Jan already created it
> https://github.com/apache/iceberg/issues/10043
>
> Jean-Baptiste Onofré 于2024年3月28日 周四16:46写道：
>>
>> Hi Walaa,
>
Hi folks,
With several people from the community, we started to craft a proposal
to design new REST Catalog Spec.
I used the "proposal process" to track this:
- The proposal "issue" is here: https://github.com/apache/iceberg/issues/10075
- The proposal document is here:
https://docs.google.com/d
gt;
> On Thu, Mar 28, 2024 at 6:59 AM Jean-Baptiste Onofré
> wrote:
>>
>> Yes, correct, thanks Manu for pointing it out.
>>
>> Thanks !
>> Regards
>> JB
>>
>> On Thu, Mar 28, 2024 at 9:55 AM Manu Zhang wrote:
>> >
>> >
at through further discussion, we can establish a robust standard
> for the catalog specification 👍
>
> - Ajantha
>
> On Mon, Apr 1, 2024 at 8:07 PM Jean-Baptiste Onofré wrote:
>>
>> Hi folks,
>>
>> With several people from the community, we started to craft a prop
used discussion (this can either be at a
> sync or we can schedule a time).
>
> -Dan
>
>
>
> On Mon, Apr 1, 2024 at 10:45 PM Jean-Baptiste Onofré
> wrote:
>>
>> Hi Walaa
>>
>> Yes, I think it makes sense to go with a vote, now that pros/cons are
>
101 - 200 of 481 matches
Mail list logo
