+1
On Thu, Sep 18, 2025 at 9:53 AM Jean-Baptiste Onofré
wrote:
> +1
>
> It sounds like a good idea to me.
>
> Regards
> JB
>
> On Thu, Sep 18, 2025 at 3:45 PM Adam Christian
> wrote:
> >
> > Howdy Polaris Community,
> >
> > I was digging through some TODOs in our codebase and I saw that there
>
+1 I think removing EclipseLink should happen soon now that we have 2
releases with it deprecated. I have
looked too deeply into this but do we have a migration plan for users
already on EclipseLink to get over to the
JDBC Impl?
On Wed, Sep 17, 2025 at 12:53 PM Dmitri Bourlatchkov
wrote:
> Thank
tionTestExtension.java:56)
... 1 more
On Wed, Sep 3, 2025 at 7:13 PM Russell Spitzer
wrote:
> I wouldn't consider it a blocker, but we should aim for tests that are
> more or less environment independent (or
> at least work on all voting dev's machines :) )
>
> If it is
, Yufei
> > > and my Mac).
> > >
> > > I propose:
> > > 1. Let's take a look on the issue created by Russell and see if we can
> > > find a fix quickly (I will investigate today).
> > > 2. If we have a quick fix, I would propose to do a RC1.
&
the
endpoint
On Wed, Sep 3, 2025 at 8:10 PM Russell Spitzer
wrote:
> This is all there is in the info logging
>
> ```
> > Task :polaris-runtime-service:intTest
> Custom actions are attached to task ':polaris-runtime-service:intTest'.
> Build cache key for task &#
; > I propose:
> > 1. Let's take a look on the issue created by Russell and see if we can
> > find a fix quickly (I will investigate today).
> > 2. If we have a quick fix, I would propose to do a RC1.
> > 3. If the fix is not obvious, then, let's aim for the
everything looks ok but the client we create
just get' a 403 for all requests I tried.
On Wed, Sep 3, 2025 at 7:16 PM Russell Spitzer
wrote:
> Full error in the error report which doesn't seem to match the StdErr
> message
>
> org.junit.jupiter.api.extension.ParameterResol
e original server startup error for further debugging.
>
> Cheers,
> Dmitri.
>
> On Wed, Sep 3, 2025 at 8:17 PM Russell Spitzer
> wrote:
>
> > Full error in the error report which doesn't seem to match the StdErr
> > message
> >
> > org.junit.jup
I wouldn't consider it a blocker, but we should aim for tests that are more
or less environment independent (or
at least work on all voting dev's machines :) )
If it is a DNS resolution error it's probably just binding to a resolved ip
rather than loopback. We had a similar
issue in Iceberg which
Verified Sigs and Checksums,
Had an issue with the build command, anyone know what the fix for this is?
```
> Task :polaris-runtime-service:intTest
RestCatalogKeycloakFileIT > initializationError FAILED
org.junit.jupiter.api.extension.ParameterResolutionException at
ArrayList.java:1596
further event instrumentation with the current set of interfaces.
> > On a related note, any major changes to the Event interfaces would
> already need to be considered as “breaking changes,” as it is already
> released and public within our Polaris 1.0.0 release.
> > There is also a pot
st saw the field name.
>
> The new proposed name 'DELETE_VIEW_METADATA_ON_DROP' sounds much more
> clear to me, or if
> we would like to stay more consistent on the term used, maybe we can
> call it 'PURGE_VIEW_METADATA_ON_DROP'?
>
> Best Regards,
> Y
My only thought on this is that usually I consider a purge a drop of the
"data" but in this case there isn't actually any data, it's only metadata.
I know we are kind of copying the old hive/Iceberg naming here where the
catalog "metadata" was considered independent from the on
disk metadata. So i
Video Link ->
https://drive.google.com/file/d/1cO7Jh8vW3Lji2WwD9Gx4GTzRhA1X6v6o/view?usp=drive_link
Meeting Purpose
Discuss Polaris community updates, including HMS integration, event API,
and task delegation service proposals.
Key Takeaways
- HMS integration: Agreement to support HMS Federa
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
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
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
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
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
+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
://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
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
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
+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
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 (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
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
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
>
+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
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
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
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
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
+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
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:
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
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
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
> > > >
>
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
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
>
> > 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
>
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
+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
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
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
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 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
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
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
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
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
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
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
+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 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)
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
>
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
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
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
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
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>
+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
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
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 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
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 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
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
; 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
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.
>
>
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
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
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
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
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
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
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
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
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
84 matches
Mail list logo
