I just worry about the wording under content moderation, the first line
says we aren't moderating but we are as it applies to the Apache COC as
noted on the third line.
```
-
User content in any form is not moderated.
-
The (P)PMC reserves the right to remove/delete commercial adver
To be clear I am +1 on this intent I just want to adjust the wording, I'll
put my suggestions on the PR
On Fri, Sep 6, 2024 at 9:51 AM Russell Spitzer
wrote:
> I just worry about the wording under content moderation, the first line
> says we aren't moderating but we are as i
Hi Y'all!
I love mailing lists but sometimes I feel like it's good to have a nice
video conference to put faces to names and discuss issues synchronously for
just a bit. I believe we've had this proposed in the past but didn't get
much of a response so I thought I'd try again.
If a majority of f
Hi y'all as note previously I have created an invite for a google meetup
for the Apache Polaris Community
First meeting is 9AM Pacific time on Thursday Oct 17th,
https://calendar.app.google/JvsMVFYtgWDf8p5g8
If you would like to be invited to all meetings in the future join the group
https://gr
I also propose to add the invite to the ASF Corporate Calendar and our
> website.
>
> Let's start Oct 17th.
>
> Regards
> JB
>
> On Fri, Oct 11, 2024 at 10:35 PM Russell Spitzer
> wrote:
> >
> > Hi Y'all!
> >
> > I love mailing lists but so
I know we've had a lot of discussions about this and I think we were hoping
to get this into the Iceberg REST API as well. I think we should try to
push the API there but I have no problem having it only within the Polaris
spec if we can't get that in. I think it has a lot of overlap with the
thing
log basis.
>
> "migrate" would be a cool feature, but I'd put it low on the priority list.
>
> Those are my thoughts, anyway.
>
> On Thu, Oct 31, 2024 at 9:22 AM Russell Spitzer >
> wrote:
>
> > Hi Y’all,
> >
> > Some of us at Snowflake
Hi Y’all,
Some of us at Snowflake and Revolut have been talking a bit about how
Apache Polaris can be used in conjunction with older implementations of
Apache Iceberg Catalogs. At Revolut, they have already built a version of
this which allows them to use Polaris Capabilities on top of an old Cata
My only minor feedback is I'd prefer we do a first release as 1.0. I think
there is an allergy to 0.1 software in production so I'd rather we just
start at 1.
On Mon, Sep 23, 2024 at 1:50 PM Jean-Baptiste Onofré
wrote:
> Hi Dmitri
>
> It makes sense to me.
>
> Regards
> JB
>
> Le lun. 23 sept. 2
Congrats everyone, the first of many welcoming emails :)
On Thu, Sep 26, 2024 at 7:41 AM Jean-Baptiste Onofré
wrote:
> Hi folks,
>
> We are very happy to announce new committers to the Apache Polaris
> (incubating) podling !
>
> * Anna Filippova
> * Eric Maynard
> * Michael Collado
> * Yufei Gu
Glad to have y'all aboard!
On Wed, Nov 6, 2024 at 11:26 AM Dmitri Bourlatchkov
wrote:
> Congratulations, Alex and Yong!
>
> On Wed, Nov 6, 2024 at 3:57 AM Jean-Baptiste Onofré
> wrote:
>
> > Hi folks
> >
> > We are pleased to announce new committers on the Apache Polaris
> > (incubating) podlin
Shouldn't we fix the license issues before the release? Seems like an
important and easy thing to do. I also think we should be excluding the
"site" directory from the release?
On Mon, Nov 18, 2024 at 4:56 PM Dmitri Bourlatchkov
wrote:
> +1 (non-binding)
>
> Validated sha512 and signature.
>
>
; https://github.com/apache/polaris/blob/e46c6cbb61e69dcb12775fa262c09437f8ee8a28/build.gradle.kts#L59-L124
> And the files listed above are excluded.
>
> Best,
> Kevin Liu
>
>
> On Mon, Nov 18, 2024 at 3:03 PM Russell Spitzer >
> wrote:
>
> > Shouldn't we fix th
I really dislike Zulip. I find it hard to use and for me all my other chats
I have to belong to are Slack for example ASF Slack and most importantly
for Polaris, the Iceberg slack. I originally didn’t have strong objections
because I hadn’t used Zulip and I was willing to try it out, but I probably
I'm strongly in favor of moving ahead with the work on the persistence
layer and improving the plugin experience/ integration
with Quarkus. I think we've really highlighted the importance lately of
improving the first time user experience with the product
and the ability to run Polaris in isolatio
I think having prebuilt pluggables is probably a good way forward. This
could also separate out some
classpath concerns as well since users wouldn't necessarily have to bundle
plugins with
dependencies they don't like on the classpath.
So +1 for runtime selection and I would prefer we actually bui
Hi Y'all,
I've been thinking a lot about cross table compatibility as well as our
ability to govern other entity types within the Polaris catalog. I think a
good first step for the catalog would be to work on providing a system for
registering non-iceberg tables and providing an API / Service capa
The proposal sounds good to me, I really don't think the details matter
that much here.
If someone is arguing the wording of the guidelines ("I waited two
mercurial days, it didn't specify in the guidelines.")
then something has gone wrong just as much as having broken them. Even if
we specified
Looks like this is fixed, but not in the RC Candidate?
Commit on RC is
aaf5d42b1959fd8d2bf617fdbe6dcf7e5b9a1eca
But commit on main is
4187721e24717dd266fb147f0ca167e1a108a995
On Tue, Jan 21, 2025 at 1:52 PM Russell Spitzer
wrote:
> -1
>
> > Task :polaris-version:compileJarTes
-1
> Task :polaris-version:compileJarTestJava FAILED
/Users/rspitzer/ValidateRelease/apache-polaris-0.9.0-incubating/tools/version/src/jarTest/java/org/apache/polaris/version/TestPolarisVersion.java:113:
error: illegal start of expression
}
^
Patch attached
On Tue, Jan 21, 2025 at 1:19 PM D
for reference I only compiled production code in my tests.
>
> On Tue, Jan 21, 2025 at 2:52 PM Russell Spitzer >
> wrote:
>
> > -1
> >
> > > Task :polaris-version:compileJarTestJava FAILED
> >
> /Users/rspitzer/ValidateRelease/apache-polaris-0.9.0-incubati
+1 (binding)
Verified
Checksum
Signatures - Note that me and JB need to verify each other's keys next time
we meet in person :)
Build and Test
Used runApp and poked to make sure nothing was broken
On Thu, Jan 23, 2025 at 6:41 PM Dmitri Bourlatchkov
wrote:
> +1 (ns)
>
> Verified:
> * Checksum
>
Congrats!
On Mon, Jan 13, 2025 at 8:46 AM Dmitri Bourlatchkov
wrote:
> Welcome Dennis!
>
> Cheers,
> Dmitri.
>
> On Mon, Jan 13, 2025 at 2:38 AM Jean-Baptiste Onofré
> wrote:
>
> > Hi folks,
> >
> >
> > We are very happy to announce Dennis Huo as new Apache Polaris
> > (incubating) podling comm
+1 Works for me (meeting on thursday)
On Sun, Jan 12, 2025 at 8:56 PM Dennis Huo wrote:
> Ah so sorry, I meant to include the proposed date of Thursday, January 16th
> for the meeting.
>
> I think it's definitely worth including the relationship to
> notifications/events in the discussion, thoug
Thursday, January 16 · 9:00 – 10:00am
> Time zone: America/Los_Angeles
> Google Meet joining info
> Video call link: https://meet.google.com/ryj-mueq-csf
>
> Thanks JB for setting it up!
>
>
> On Mon, Jan 13, 2025 at 11:15 AM Russell Spitzer <
> russell.spit...@gmail.com>
Hurrah!
On Wed, Jan 8, 2025 at 9:05 AM Anurag Mantripragada
wrote:
> Congratulations, Dimitri!
>
> Best,
> Anurag Mantripragada
>
>
>
>
>
>
> > On Jan 8, 2025, at 1:23 AM, ConradJam wrote:
> >
> > Congrats!
> >
> > Dmitri Bourlatchkov 于2025年1月8日周三 05:36写道：
> >
> >> Thanks for the warm welcome,
I'm not sure it is so clear cut, while we may say it's a work in progress
there are a lot of users of the current codebase at least from our
perspective. While this shouldn't be a blocker for every change it
definitely cannot be ignored wholesale. The current branch *is* in use in
production and I
I think I saw in the other document you had some benchmarks with a less 1N
to 1T ratio? Could we run some of those as well? It would be great to have
something with closer to a 1 Namspace to 100 tables sort of layout.
On Wed, Mar 19, 2025 at 3:06 PM Pierre Laporte
wrote:
> Just a heads up, I upd
ache/polaris/issues/1044
> [2] https://github.com/apache/polaris/issues/1076
> [3] https://github.com/apache/polaris/issues/1123
>
>
> --
>
> Pierre
>
>
> On Sat, Mar 22, 2025 at 3:47 PM Russell Spitzer >
> wrote:
>
> > I think it makes sense for us to
Sounds good, Although I'm also fine with doing votes on design docs prior
to PR's if that makes more sense. But generally having some gateway of
"these changes are going to be implemented"
On Fri, Mar 14, 2025 at 3:11 AM Robert Stupp wrote:
> +1
>
> on Dmitri's proposal
>
> On 14.03.25 07:52, Je
Strongly in favor of this. I'm ok if it's just built jars (not including
docker code)
but if we think that's possible to do at the same time I'm fine with that
as well.
I would really like us to have some jars that are officially released,
even if
they are a pre-1.0 experimental sort of build.
On
Looks good to me, Didn't we have some Polaris talks around as well? I think
there were some community events within the last reporting period.
On Fri, Mar 14, 2025 at 4:38 AM Robert Stupp wrote:
> +1
>
> On 03.03.25 20:14, Dmitri Bourlatchkov wrote:
> > Thanks JB!
> >
> > The report looks good t
That sounds great to me, we could hot link it to issues, it would be nice.
Or even have it just as a project?
On Tue, Mar 18, 2025 at 1:37 AM Jean-Baptiste Onofré
wrote:
> By the way, what do you think about adding the maturity model as
> GitHub Discussion (as we have the roadmap) ?
>
> Please l
Does
> everybody agree with that statement?
>
> --
>
> Pierre
>
> On Wed, Mar 19, 2025 at 9:33 PM Russell Spitzer >
> wrote:
>
> > I think I saw in the other document you had some benchmarks with a less
> 1N
> > to 1T ratio? Could we run some of those
I'm not convinced that keeping it in the main repo is necessary but I don't
think that's really
important at this time. I think it's simple enough to move the code out
later if we find that
we've run up against some other limitations of testing or releasing. So I'm
fine with beginning
in the main r
>
> > Howdy folks!
> >
> > Snowflake's IT department manages the domains. We just need to make a
> > request internally. I'll track down who it is and get it started.
> >
> > We should also work to transfer the domain to ASF properly as part of any
>
+1
On Tue, Mar 25, 2025 at 4:07 AM Robert Stupp wrote:
> Hey Dennis,
>
> +1 on your proposal and thanks for especially marking it as
> "experimental, subject to change".
>
> On 25.03.25 05:28, Dennis Huo wrote:
> > Hello all,
> >
> > We've had some productive discussion in various places on the
I think having a tool like this is a great idea. Would we be able to host
the results over time as well? Like an official build run that triggers on
a daily basis?
On Wed, Mar 19, 2025 at 10:07 AM Pierre Laporte
wrote:
> Hi
>
> I have been working on a set of benchmarks for Polaris [1] and would
Hi y'all!
I'm excited to let the Polaris Community know that the PPMC has added three
new members. Dmitri Bourlatchkov, Dennis Huo and Yufei Gu are all now
members of the Polaris PPMC.
Please join me in welcoming them,
Russ
gt; > > > we will always be able to replace Scala or find alternative (to the
> > > > benchmark tool) if there's an ask from the community.
> > > >
> > > > My $0.10 :)
> > > >
> > > > Regards
> > > > JB
> > > >
>
ast report ? I
> can check quickly :)
>
> Regards
> JB
>
> On Fri, Mar 14, 2025 at 4:39 PM Russell Spitzer
> wrote:
> >
> > Looks good to me, Didn't we have some Polaris talks around as well? I
> think
> > there were some community events within the last
Great news!
On Wed, Apr 16, 2025 at 10:04 AM Jean-Baptiste Onofré
wrote:
> Hi folks,
>
> I received several requests to get Polaris SNAPSHOT artifacts
> published (to build external tools, or from polaris-tools repo).
>
> I did a first SNAPSHOT deployment:
> https://repository.apache.org/content
Hurrah!
On Mon, May 5, 2025 at 11:11 AM Neelesh Salian
wrote:
> Congratulations to all of you!
>
> Regards,
> Neelesh S. Salian
>
>
>
> On Mon, May 5, 2025 at 09:08 Yufei Gu wrote:
>
> > Congrats everyone!
> >
> > Yufei
> >
> >
> > On Mon, May 5, 2025 at 6:14 AM Dmitri Bourlatchkov
> > wrote:
+1 (binding)
1. ➜ apache-polaris-0.10.0-beta-incubating shasum -a 512 --check *.sha512
apache-polaris-0.10.0-beta-incubating.tar.gz: OK
polaris-quarkus-admin-0.10.0-beta-incubating.tgz: OK
polaris-quarkus-admin-0.10.0-beta-incubating.zip: OK
polaris-quarkus-server-0.10.0-beta-incubating.tgz: OK
p
I think it's also perfectly fine to change docs after the release. We would
do so if we had better
descriptions or bug fixes, so I don't see why we couldn't do that for
better how-to guides
as long as the information applied to 0.10.
On Mon, May 5, 2025 at 4:31 PM Dmitri Bourlatchkov wrote:
> Hi
I'm strongly in favor of having a timeboxed Agenda. I do want to make sure
we always poll new attendees first. I'm not sure this would fit into our
agenda but the Parquet sync usually does a roll-call and "what are you
interested in?" at the top of the hour. We probably have too many people
for tha
I think this would be a great thing to include as well! Polaris examples
seems like a fine place to put it, not sure labs is as appropriate since
wouldn’t be using the repo for experiments
On Wed, Feb 19, 2025 at 12:54 AM Jean-Baptiste Onofré
wrote:
> Hi Kamesh
>
> Thanks for sharing ! That's co
+1 (binding)
On Mon, Feb 17, 2025 at 1:36 PM Jean-Baptiste Onofré
wrote:
> Hi folks
>
> We merged the fix about DISCLAIMER and NOTICE.
>
> I will proceed with 0.9.0 rc6 vote.
>
> Stay tuned !
>
> Thanks
> Regards
> JB
>
I'll ping internally as well
On Sun, Mar 9, 2025 at 12:40 AM Jean-Baptiste Onofré
wrote:
> Hi folks,
>
> Where are we about redirect polaris.io to polaris.apache.org ?
>
> I just checked: polaris.io still use a old documentation and not fully
> compliant with The ASF trademarks policy.
> Maybe @
+1
On Fri, Feb 21, 2025 at 11:31 AM Eric Maynard
wrote:
> Obligatory +1 as it's my issue -- I'm also open to less frequent.
>
> My pitch: This is an upper bound on how often we update dependencies, not a
> lower bound. If an actual person sees an actual reason to update a
> dependency, they can
+1
On Thu, Feb 20, 2025 at 6:06 AM Jean-Baptiste Onofré
wrote:
> +1 (binding)
>
> Regards
> JB
>
> Le lun. 17 févr. 2025 à 21:27, Jean-Baptiste Onofré a
> écrit :
>
> > Hi folks,
> >
> > After the vote on the incubator general mailing list, we fixed the
> > DISCLAIMER content and cleaned up the
I think it makes sense for us to also build some capabilities into the
tools repo to build Polaris at a specific commit for testing purposes. If
the Spark Catalog and Benchmarking code goes there they could both share
this code for testing, ditto for the migration code.
On Fri, Mar 21, 2025 at 4:5
+1
1. Verified Cheksums, Build, run
Server - Dist:
Checked licences and notices in all Jars
Everything looks the same as on the PR we did for RC2 to fix up licenses
I saw notices that still had dual licenses but the text looks
directly copied and both licenses are green (Apache + Ecli
but forgot to update in helm chart. I have
> to fix that.
> For dual license I did a pass but I have to missed some.
>
> Regards
> JB
>
> Le mar. 20 mai 2025 à 19:44, Russell Spitzer a
> écrit :
>
> > +1
> >
> > 1. Verified Cheksums, Build, run
>
The only multiple locations table formats I'm currently aware of are Hive
(partitions can live wherever) and Iceberg.
I think for Delta, Hudi, LanceDB, Paimon and File based tables they all
have to live in the root location. I'm not sure of any other "file" based
tables where this would be an iss
mutual understanding of all parties dealing with Generic
> Tables.
>
> Open API yaml comments are not sufficient, IMHO. I'd prefer to have a
> dedicated doc page to define expectations and compliance.
>
> Thanks,
> Dmitri.
>
>
> On Mon, May 19, 2025 at 2:17 PM Russe
You could add in some of the events that have been hosted recently, I know
you presented at them :)
Might also be nice to list some of the recent proposals brought to the
community just to show the amount of interest.
+1 though
On Tue, May 27, 2025 at 11:12 AM Yufei Gu wrote:
> Thanks JB for d
+1
On Wed, May 28, 2025 at 10:49 AM Jean-Baptiste Onofré
wrote:
> Gentle reminder on this RC. I plan to close the vote soon (we already
> have enough binding votes, but I would like to give a chance to take a
> look).
>
> Thanks !
> Regards
> JB
>
> On Fri, May 23, 2025 at 5:24 PM Jean-Baptiste
These seem like good ideas to me. I'd prefer things with minimal human
interactions in the loop but
having dev emails for changing intra-release breaking commits sounds good
to me.
On Thu, May 15, 2025 at 2:30 PM Yufei Gu wrote:
> Thanks for kicking this off, Dmitri—great idea!
>
> Looking at t
Thanks to Scott and Dmitri for two nice design proposals
https://github.com/apache/polaris/pull/1654
https://github.com/apache/polaris/pull/1655
Quoting what I wrote on 1654
How about we wait till 5/28 and link all alternatives in the parent issue
https://github.com/apache/polaris/issues/1653 an
+1 (Binding)
Checked all the normal things
1. Build / Test
2. Checksums
3. Smoke tested Server and Admin jars
4. GPG Signatures (Issues below)
Only did a quick pass on Helm Licenses/Notice and Friends but all look good
to me now.
I do have one question because I seem to be having issues (if this
+1 (binding)
-Verified Checksums and Sigs
-Verified all build and test again
-Rechecked the license fixes we did in the past RC's
On Wed, Jul 2, 2025 at 2:46 PM Dennis Huo wrote:
> +1 (binding)
>
> -Verified all checksums
> -Verified compile from source tarball
> -Verified setting feature confi
I think having some integration with HMS is definitely a good idea. We've
already seen
users build this in the wild on top of Polaris showing that there is
definitely a demand.
I'm still a strong believer that we should be helping users get to Polaris
from whatever systems
they are currently using
I do like this proposal because it essentially avoids all the issues that
Robert mentions by instead just offering the ability for a client to decide
in advance which commits would succeed. Leaving more advanced automatic or
server side determined deconfliction is a good future direction but I thin
For me there are two big use cases for this:
1. Simple overwrite.
I may have several jobs, for example one that does TTL , the command it
runs is idempotent and always deletes all rows / files before a certain
point. The other is a merge/update command. In this situation I don't even
need to recon
Since all the artifacts are going to change their names when Polaris
graduates (hopefully) I don’t think we should over index on having
everything settled at this moment
Given that this is part of an experimental feature it doesn’t seem to me
like it’s worth delaying the release for alignment on
Just checked and Airflow has this same issue -
helm repo add apache-airflow https://airflow.apache.org
helm pull apache-airflow/airflow --untar
head airflow/Chart.yaml
---
annotations:
artifacthub.io/changes: |
- description: Add extra secret annotations to most secrets
kind: added
://solr.apache.org/charts
"apache-solr" has been added to your repositories
helm pull apache-solr/solr --untar
head solr/Chart.yaml
annotations:
artifacthub.io/alternativeName: solrcloud
artifacthub.io/category: database
artifacthub.io/changes: |
On Mon, Jun 30, 2025 at 10:59 AM Russe
PR Fixing up the license issue in the Spark Client Jar -
https://github.com/apache/polaris/pull/1950
I wasn't able to get the Shadow Jar to do it with built in functionality so
I brute forced it. If someone has a better approach I would suggest doing
it as a followup unless there is time to do it r
I'm fine with the plan although I think we should probably change step 4 to
allow both the current implementation and the new implementation to exist at
the same time with a flag for switching over to the new task implementation.
While the new implementation may be much better, it is a pretty si
70 matches
Mail list logo
