+1
On Fri, Sep 19, 2025 at 4:48 PM Alexandre Dutra wrote:
>
> Hi,
>
> Heads up: I am going to merge the PRs in about one hour.
>
> Thanks,
> Alex
>
> Le mar. 16 sept. 2025 à 19:54, Alexandre Dutra a écrit :
>
> > Sorry, I forgot a 3rd PR, also already approved:
> >
> > 3) Remove ActiveRolesProvi
2nd-ing my approval on the PR: +1
On Thu, Sep 18, 2025 at 6:03 PM Alexandre Dutra wrote:
>
> +1 to all proposed rules.
>
> On Thu, Sep 18, 2025 at 5:29 PM Russell Spitzer
> wrote:
> >
> > +1
> >
> > On Thu, Sep 18, 2025 at 9:53 AM Jean-Baptiste Onofré
> > wrote:
> >
> > > +1
> > >
> > > It soun
+1 on "officially" deprecating EL in 1.2 + removing it in 1.3
On Thu, Sep 18, 2025 at 7:53 AM Jean-Baptiste Onofré wrote:
>
> Hi,
>
> I agree with Yufei:
> 1. I would announce EclipseLink will be removed in 1.3
> 2. We do remove it in the 1.3 release
> 3. I don't think we need any tool: moving fr
I can keep that. But no issue or PR has that label, so it's unused.
On Thu, Aug 21, 2025 at 8:20 AM Yufei Gu wrote:
>
> Why do we remove the 1.1.0-blocker?
>
> Yufei
>
>
> On Wed, Aug 20, 2025 at 11:15 PM Robert Stupp wrote:
>
> > SGTM
> >
> > I
ls", but "relax" about the use
> of temporary labels (when it makes sense).
>
> Regards
> JB
>
> On Wed, Aug 20, 2025 at 10:55 AM Robert Stupp wrote:
> >
> > Hi all,
> >
> > We currently have a lot of GitHub labels for issues and pull requests
Thanks for the summary.
Really appreciate the focus on the API first, get consensus on that
and after that tackle the implementations.
Looking forward to the events API proposal!
On Tue, Aug 19, 2025 at 8:39 AM Jean-Baptiste Onofré wrote:
>
> Hi folks,
>
> Thanks everyone for participating in t
Thanks a lot for tackling this, Pierre!
It's very difficult to figure out all new features, changes and fixes
"after the fact".
I think we should establish a culture to _proactively_ populate the
content of CHANGELOG.md _within_ each applicable PR instead of asking
weeks or months later, or havin
Hi,
I've been looking into untangling the strong coupling of storage
credentials and persistence. Storage (think: S3, GCS, etc), storage
credentials and persistence are very different things IMO. This
coupling also needs to be removed to allow tasks to be executed
"anywhere", without having to loa
Hi all,
We currently have a lot of GitHub labels for issues and pull requests.
Many of the labels serve(d) a temporary purpose, have no clear meaning
or are superfluous as GitHub offers more sophisticated approaches. The
following list serves as a proposal to apply to the project's list of
labels.
- Is there any client/server caching we can add?
> > - Are we considering batch signing?
> > - Should we add rate limiting to avoid endpoint abuse?
> >- How do clients like Spark, Trino discover and use the signing APIs?
> >
> > Yufei
> >
> >
Hi all,
I don't see any other changes, besides what's already mentioned, that
can make it for the 1.1 "train car".
Robert
On Wed, Aug 20, 2025 at 12:26 AM Yufei Gu wrote:
>
> Hi JB,
>
> Make sense to move some enhancement and proposals to 1.2. e.g., Support for
> OpenLineage. Some of 1.1 items
40 PM Prashant Singh
> > > > wrote:
> > > > >
> > > > > IMHO encoding stuff in the url so that we can avoid reverse lookup
> > is the
> > > > > right thing to do !
> > > > > Since we are relying on this, signing by a key
+1
On Sat, Aug 16, 2025 at 6:22 AM Dmitri Bourlatchkov wrote:
>
> Hi All,
>
> I propose to add [1] a new feature flag PURGE_VIEWS_ON_DROP to allow
> dropping views when DROP_WITH_PURGE_ENABLED is false (default).
>
> The default value of PURGE_VIEWS_ON_DROP is true to match prior behaviour.
>
> A
Hi all,
I just figured out that there is a chance of running into OOMs when
purging tables. Even if an OOM does not occur, there is a huge amount
of heap pressure that deserves broader attention.
TL;DR all manifest-files are materialized on heap at once as base-64
encoded strings (~ +33%) on the
ll. As long as we add a field
> > > > other than the realm ID to the realm context, there is no way to
> > > construct
> > > > a realm context from another node just by realm id.
> > > >
> > > > Yufei
> > > >
> > > >
+1 to the proposal and unifying all the rather duplicated implementations.
> may have to bootstrap (new) realms multiple times without redeploying Polaris.
I'm not sure that this can work today, because the valid realms are
statically configured via 'polaris.realm-context.realms', so you'd
need t
Merging those two things SGTM.
It's what Quarkus/Vert.X
'HttpAuthenticationMechanism'/'SecurityIdentity' do (right).
On Wed, Aug 13, 2025 at 1:55 AM Dmitri Bourlatchkov wrote:
>
> Thanks for starting this thread, Alex!
>
> I fully support merging Authenticator and ActiveRolesProvider.
>
> Aside f
more complex than simply copying the context whenever needed.
>
> Yufei
>
>
> On Tue, Aug 12, 2025 at 6:18 AM Robert Stupp wrote:
>
> > Hi all,
> >
> > quick heads up that there's a PR to remove CallContext.copy(), which
> > is only used from tasks.
Hi all,
quick heads up that there's a PR to remove CallContext.copy(), which
is only used from tasks. This change is also part of the effort to
have async & reliable tasks running "anywhere".
Robert
[1] https://github.com/apache/polaris/pull/2294
Hi all,
Recently it became apparent that the community has no single opinion
about what an integration point that downstream consumers can rely on
in terms of availability, stability and most importantly functional
and behavioral contracts is.
The Polaris code base itself is still pretty fresh/yo
Hi all,
While looking into how “purge table”, or any other Iceberg table/view
related operation, can be integrated into the tasks handling
proposals, it became apparent that retrieving an Iceberg `FileIO`
instance requires a bunch of operations.
For posterity: the async-reliable-tasks proposal [1
Hi all,
Description of the PR: Having the role-arn parameter required for a catalog
is redundant in many and requires the generation of an extra role in cases
when IRSI (for AWS) is being used. Other S3 implementations (Minio, Ceph,
many of the appliances) also do not all require a role-ARN.
See
ll/1
>
> I would appreciate it if you could take some time to run through the
> quickstart and share your thoughts, questions, or any concerns you
> have in this thread or directly on the pull request.
>
> Bests,
> William
>
>
> On Tue, Jul 15, 2025 at 2:24 AM Robert Stupp
e "On-Premise S3 & Remote Signing" GitHub issue [2].
> >
> > [1] https://github.com/apache/polaris/issues/1530#issuecomment-3138005897
> > [2] https://github.com/apache/polaris/issues/32#issuecomment-3144991873
> >
> > Cheers,
> >
> > Pat
> >
> &
, 2025 at 2:18 PM Alexandre Dutra wrote:
> >
> > Hi all,
> >
> > Here is the PR:
> >
> > https://github.com/apache/polaris/pull/2233
> >
> > Thanks,
> > Alex
> >
> > On Fri, Aug 1, 2025 at 12:51 PM Robert Stupp wrote:
> >
> > > > >
> > > > > Considering the current issues, I don't think it's worth the effort
> > to
> > > > > keep the current implementation.
> > > >
> > > >
> > > > It seems risky to me to not support
sely related classes.
> 2) I am not sure everybody is on board with the split. I think we will
> need a new DISCUSS thread for that and maybe even a proposal doc. I'd
> suggest tackling that after the merge.
>
> Does that make sense?
>
> Thanks,
> Alex
>
> On Fr
x27;d prefer to respond with 429 (Too Many Requests) in that case (as I
> mentioned earlier).
>
> [1]
> https://github.com/apache/iceberg/blob/b1c8bc589e0caae3d0a1649e354c44d0fb23759c/core/src/main/java/org/apache/iceberg/rest/ErrorHandlers.java#L184-L185
>
> Cheers,
> Dmitri.
&
do things the other
> >> > way around, and move the configuration classes from the
> >> > polaris-runtime-service module to the polaris-service-common module.
> >> >
> >> > BUT: my main point for proposing this change still holds: *the two
> >&g
ing "uber-module" into smaller, concern-specific
> > > modules like "polaris-service-auth", "polaris-service-telemetry",
> > > "polaris-service-events", etc. This approach would make it much
> > > simpler for integrators to implement thei
Hi,
not sure whether exposing the object storage credentials given to
Polaris to all clients isn't going to cause a "false impression of
security" (aka: "our credentials are vended by Polaris, so we're safe"
- nope...).
With my "evil user" hat on, I'd try to figure out the configuration
option (is
Is the issue here just the configuration types or is there more?
For the config types, I think we can get away by having the
smallrye-config annotations on the "parent" interface.
My concern is that polaris-runtime-service is rather the Quarkus specifics.
CDI is great, just Quarkus isn't the only
Having retries would be great.
However, for namespace property updates, the situation is undefined,
because there are no "prerequisites" that have to be satisfied.
Say, you have two concurrent requests:
- One requests sets a=b
- Another request removes a
- Yet another request sets a=c
Technically
+1 (binding)
NB: I tried to compare the binary artifacts against locally built ones
from the Git tag, which sadly doesn't work yet. I've opened an
enhancement issue [1] to eventually have that ability, which would
make it pretty straightforward to compare the binary artifacts against
the source tr
previously discussed.
> I also have opened a PR demonstrating what the Delegation Service
> looks like here:
>
> - https://github.com/apache/polaris/pull/2193
>
> WDYT?
>
> Bests,
> William
>
> On Thu, Jul 24, 2025 at 11:18 AM Robert Stupp wrote:
> >
> > Hi,
&g
he approach in general, I can follow up with a
more concrete implementation including the "purge table" use case and
maybe another example use case.
Robert
[1] https://lists.apache.org/thread/ph10th4ocjczpf5gz17mqys4fkp5qrzw
[2] https://github.com/apache/polaris/pull/2180
On Mon,
Hi all,
we can also do another "full" release from main and just call it
"1.1.0", even if there's "not much new in it". But I think even that
"not much" is more than what people would expect from a "point" or
"dot" or "patch" release (bug and security fixes).
Mean, we already have some support for
h a
> > dedicated tag and source distro) and then move forward on separate repo
> > after this release ?
> > We can “unblock” the users with an official release and then prepare the
> > next release.
> >
> > Regards
> > JB
> >
> > Le lun. 21 juil.
.org
> > > >> >> > > >
> > > >> >> > > > > wrote:
> > > >> >> > > > >
> > > >> >> > > > >> I also think that the compatibility between helm charts
&g
> > > >> going
> >> >> > to
> >> >> > > > make
> >> >> > > > >> maintenance easier (to recap: I originally supported more
> >> >> > > > >> frequent /
> >> >> > > >
,
> > is a big deployment change.
> >
> > Perhaps we could implement the password reset request for existing Polaris
> > Principals, while gradually enhancing support for external IdPs and making
> > it default at some point.
> >
> > Cheers,
> > Dmitri.
>
; Thanks,
> Alex
>
> On Thu, Jul 17, 2025 at 11:14 AM Robert Stupp wrote:
> >
> > That's correct. That "dependency hell" wouldn't exist.
> >
> > Another aspect is that the integration tests all require their
> > "custom" Quarkus
oughts?
On Thu, Jul 17, 2025 at 9:26 AM Robert Stupp wrote:
>
> Events, once they're "in the code base" are pretty much a "public
> facing API", which I think justifies careful handling and
> re-iteration, especially given the IRC work.
>
> With resp
That's correct. That "dependency hell" wouldn't exist.
Another aspect is that the integration tests all require their
"custom" Quarkus build, which would not be necessary with the
apprunner, leading to faster CI.
On Wed, Jul 16, 2025 at 3:42 PM Dmitri Bourlatchkov wrote:
>
> I was reviewing our
Hi all,
We now have an interface `UserSecretsManager` for safe storage of
secrets (thanks Dennis!).
With that interface we just have one implementation named
`UnsafeInMemorySecretsManager`, which is pretty much what the name
says. For posterity: it does not persist secrets but only keeps those
in
uted. I’ll consider this
> > time
> > > > > limit in effect unless there’s explicit and valid pushback.
> > > > >
> > > > > I do also prefer delegation over adding "all concerns to a single
> > > > > > class". It simplifies
ase however, we have a branch release/1.0.x which looks like we
> would not cut new releases from. Rather, the branch itself represents the
> 1.0 release and accordingly I think renovatebot should not be automatically
> opening PRs against that branch.
>
> --EM
>
>
>
> On T
s like we do not.
>
> On Tue, Jul 15, 2025 at 5:18 AM Robert Stupp wrote:
>
> > Oh!
> > According to the dependency dashboard [1] it works on both main and
> > release/1.0.x :)
> >
> > [1] https://github.com/apache/polaris/issues/642
> >
> > On Tue
Oh!
According to the dependency dashboard [1] it works on both main and
release/1.0.x :)
[1] https://github.com/apache/polaris/issues/642
On Tue, Jul 15, 2025 at 2:16 PM Robert Stupp wrote:
>
> Yea - it already created 5 PRs (the hourly limit). Let's see whether
> it catches the
JB
>
> On Tue, Jul 15, 2025 at 2:03 PM Robert Stupp wrote:
> >
> > Hi all,
> >
> > I did some investigation on what's going on with Renovate, why it's no
> > longer working.
> >
> > It seems to be broken by my PR [1] to let Renovate sugg
Hi all,
I did some investigation on what's going on with Renovate, why it's no
longer working.
It seems to be broken by my PR [1] to let Renovate suggest patch
version updates on 1.* release branches [1], which was done knowing
that Renovate supports multiple base branches in forking-Renovate [2]
Hi all,
Writing the following with my "nasty security guy" hat on:
Generally speaking, storing secrets is a quite sensitive topic that
deserves a lot of attention upfront, during the initial implementation
and for all changes related to it. What we already have in Polaris is
IMHO strictly speakin
ple
> >credentials and user contexts. It aligns well with multi-tenant needs.
> >
> > Given that, I think we have a clear path forward for enabling multi-tenancy
> > with HMS federation. Introducing implicit authentication as a starting
> > point seems reasonable. It can
ts,
> William
>
> On Wed, Jul 9, 2025 at 7:36 AM Robert Stupp wrote:
> >
> > Hi all,
> >
> > Overall Polaris deserves a thorough asynchronous task handling
> > infrastructure.
> >
> > The general difference to my proposal [1] is that this one
If the consensus is to have a different release cadences for the
Polars helm chart and Polaris "server", I propose to move the helm
charts to polaris-tools. One difference between the two repos is that
the "main" repo eventually gets (semi) automatic releases that might
get confused with rather man
ate to better
> align with what you're looking for? The docs
> <https://docs.renovatebot.com/configuration-templates/#pr-body> seem to
> suggest that it can be done with e.g. {{{commitList}}}
>
> --EM
>
> On Wed, Jul 9, 2025 at 9:08 AM Robert Stupp wrote:
>
> &
Hi all,
> work done by AWS on this that resulted in the fine-grained commits proposal.
> The idea there was to send the changes that the client is making to the
> content-metadata tree to the service.
Agree that this is the way to go and I propose to start with this and
then see if and what els
The invite says July 16th?
On Wed, Jul 9, 2025 at 8:02 PM Jean-Baptiste Onofré wrote:
>
> Hi folks,
>
> Several contributors asked an update about NoSQL support in Apache Polaris.
>
> Now that Polaris 1.0 is almost there :) I propose to have a meeting to
> resume the discussion.
>
> I scheduled a
My biggest concern is the Renovate PRs. The commit message of those is
suitable for being merged "as is" - but the PR description is not.
Given the amount of Renovate-PRs it's a lot of cognitive work to
adjust those - or the commit log would look really really awful with a
ton of not useful informa
9, 2025 at 12:17 PM Robert Stupp wrote:
>
> Let's recap what Polaris offers:
> 1. Multi tenancy via realms
> 2. Multiple catalogs per realm
> 3. OAuth/OIDC
>
> Adding Kerberos is global per JVM, making #1 impossible and likely
> also not suitable for #2, plus adding
Hi all,
Overall Polaris deserves a thorough asynchronous task handling infrastructure.
The general difference to my proposal [1] is that this one is a
dedicated service. It seems that there will be different
implementations of task types depending on whether those are run
inside Polaris or inside
T.
> > >
> > > 4. That depends on what you mean by "depends on" -- it could also be said
> > > that Iceberg itself depends on Hadoop.
> > >
> > > 5. This not only also applies to HADOOP federation, which already exists,
> > > but also does *not* app
Hi all,
>From experience in the past, the initially created PR summary and
description do not fully match the eventually merged change.
This is why I mentioned "... contributors should review the PR summary
and description before opening a PR and committers should really
review both the summary an
a good future direction but I think
> it’s orthogonal to this proposal.
>
>
> On Tue, Jul 8, 2025 at 3:19 AM Robert Stupp wrote:
>
> > The general idea to resolve commit-conflicts in Polaris is fine.
> > However I miss some information about the tricky details.
&g
The general idea to resolve commit-conflicts in Polaris is fine.
However I miss some information about the tricky details.
The tricky part is how to detect and in turn how to resolve those
conflicts. That requires knowledge of the change being performed and
its context.
While it sounds simple to
on-binding votes. This vote will pass if there are 3
binding +1 votes and more binding +1 votes than -1 votes.
NB: if this vote passes, a new vote has to be started on the Incubator
general mailing list.
Yufei
--
Robert Stupp
@snazy
this vote thread on July 3rd.
That said, we do have enough binding votes. (+1: 4, -1: 0, 0:0).
Therefore the vote has passed.
- Ajantha
On Fri, Jul 4, 2025 at 3:57 PM Robert Stupp wrote:
+1
This vote is running for ~10 days now, guess it's time to count the
votes. I only see +1s, so go ah
that it does not natively manage. Please let me know
if you have any thoughts or feedback.
Thanks,
Pooja
--
Robert Stupp
@snazy
e is configured as OAUTH, that doesn't mean
that
the remote catalog isn't additionally using mTLS. It just means that
the
ConnectionConfigInfo attached to the EXTERNAL catalog in Polaris
contains
OAUTH-related information.
--EM
--
Robert Stupp
@snazy
all burden on ASF
runners.
I think this change could speed up our iteration process.
Note: We already follow this style at apache iceberg and it worked great so
far for contributors and the community.
I will open an INFRA team ticket at ASF once we have enough binding votes
on this.
- Ajantha
+1
On 26.06.25 23:55, Dmitri Bourlatchkov wrote:
Hi All,
Posting for visibility.
In PR [1955] I propose to avoid serializing null property values to clients.
This change does have some risk of breaking existing clients, but the risk
is minimal IMHO. Only clients that rely on observing explici
Yufei,
I think it makes the most sense to focus on the issues at hand.
The license/notice issues are serious. Users have to be able to identify
the correct license/notice and not guess from a bunch of different
licenses/notices from other projects.
The changed cherry-picked commit onto the r
Strike my comment about helm charts.
On 24.06.25 08:56, Robert Stupp wrote:
Adding:
Helm chars are missing as well
On 24.06.25 08:39, Robert Stupp wrote:
-1 (binding)
Overall reasons for the -1:
* zip/tarball/images missing
* license/notice issues
* broken(?)/different commit content
Zip
on-oriented and
doesn't help move the conversation forward - providing reasonable
suggestions that help resolve these concerns is what truly helps. Please
work with me to propose something that you wouldn't have concerns on.
Best,
Adnan Hemani
On Mon, Jun 23, 2025 at 3:15 AM Robert Stupp wro
ducing error handling could break that
pattern. So the real question is: is there a compelling reason to change
the current behavior and add error handling to Events? The responsibility
to prove that this change is clearly beneficial lies with those proposing
it.
Best,
Adnan Hemani
On Mon, Ju
Adding:
Helm chars are missing as well
On 24.06.25 08:39, Robert Stupp wrote:
-1 (binding)
Overall reasons for the -1:
* zip/tarball/images missing
* license/notice issues
* broken(?)/different commit content
Zip and tarball binaries for `polaris-server` and `polaris-admin` are
missing in
-1 (binding)
Overall reasons for the -1:
* zip/tarball/images missing
* license/notice issues
* broken(?)/different commit content
Zip and tarball binaries for `polaris-server` and `polaris-admin` are
missing in the Maven publication.
Docker images for `polaris-server` and `polaris-admin` ar
Not "labeled" as blockers, but two things to clarify:
1. The "[DISCUSS[ Spark Client jars: maven coordinates and shading" thread
2. Having the docs for a release appear in a URL containing "in-dev"
doesn't feel right.
The first one might have implications to the release?
On 23.06.25 13:30,
k on either of these topics - but
reiterating already responded-to threads with no new
information/opinions/suggestions does not help drive the discussion forward IMO.
Best,
Adnan Hemani
On Jun 20, 2025, at 7:29 AM, Robert Stupp wrote:
Thanks for bringing this up.
I referenced the concerns that
prefer as little conversation
latency as possible, so please do list all concerns as thoroughly as
you can. Going through fractional concerns little-by-little will only
make our time to resolve concerns unnecessarily longer.
Best,
Adnan Hemani
On Jun 20, 2025, at 6:01 AM, Robert Stupp wrot
xt, the above Mailing List thread has been open for over a
month detailing all of this and did not receive these concerns at any time
regarding this. It is immensely frustrating that contributors follow all the
processes recommended - yet still end up with the possibility of wasted efforts
at t
Thanks for bringing this up.
I referenced the concerns that were mentioned on the PR about
* the approach not using a `@Decorator`, mixing concerns.
* exception/failure handling.
For me, these are important topics that need to be considered in the PR.
It would be good to respect those concerns
Adding that there's been consensus in the meeting to start with a pure
Java interface and go from there.
I'm not sure that the statement "Ordering guarantees are **only**
possible ... event creation time" (emphasis mine) is correct.
During the meeting I mentioned that I strongly believe that
vate and other bots to skip release candidates. In this
scenario, when the release passes, the release manager would simply
push another image to the same repository without the "rcX" suffix.
Does that sound like a reasonable compromise?
Thanks,
Alex
On Fri, Jun 13, 2025 at 1:53 PM
b.com/apache/polaris/pull/1890
Yufei
On Fri, Jun 13, 2025 at 4:53 AM Robert Stupp wrote:
I was thinking of how the Docker images are being staged and eventually
released. I know there was a dev-ML thread about this, but I think this
topic is important for the 1.0 release, so raising it here
lease/0.9 for now as we did a release on this
branch, so we could have a request from the community to do a new
release (0.9.1, etc), even if I don't think it will happen :)
Regards
JB
On Fri, Jun 13, 2025 at 1:56 PM Robert Stupp wrote:
Deleting the release/0.9+10 branches is fine for me.
Hey Adnan,
this is pretty short notice and not everybody will have had a chance to
see this message. So we give people quite a few days for those.
Also, please schedule those via JB, so we can use recording et al.
Robert
On 14.06.25 01:43, Adnan Hemani wrote:
Hi all,
As we were not able to
Hi,
as of today, every committer to Polaris is mentioned in the CODEOWNERS
file. This forces every committer to receive an email for every PR
creation, every comment, every merge and so on - quite a lot of emails
every day. IMHO it's already quite difficult to prioritize those or even
figure
that.
Agree to keep the "branches clean".
Regards
JB
On Thu, Jun 12, 2025 at 10:26 AM Robert Stupp wrote:
Hi guys,
I noticed that there are a bunch of stale branches and branches that
look like experiments in the Polaris GitHub repository
https://github.com/apache/polaris/ (see b
e google
spreadsheet here:
https://docs.google.com/spreadsheets/d/1GyLvp2cdYwioOsBwszNWiphZt_IIdo4LIfsZBFV88mc/edit?usp=sharing
Yufei
--
Robert Stupp
@snazy
vention. The name
"release/x.y.z" is part of an example. We should add that name convention
to the guidelines.
[1] https://polaris.apache.org/community/release-guide/
Yufei
On Thu, Jun 12, 2025 at 11:07 AM Robert Stupp wrote:
Heads up: It's also documented in the release-guid
any 1.0-blocker,
we are good to start rc.
We can also chat about that during the community meeting today.
If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on the
main branch mainly about license/notice etc).
Thanks !
Regards
JB
Le jeu. 12 juin 2025 à 10:10, Robert Stupp a
.com
wrote:
+1 to making 801 a blocker.
Based on Alex's comments in 1799, it looks like the rotation is
only
happening in JdbcMetastoreManagerFactory? If so, I think we
have a
very
simple fix in PR#1804 <
https://github.com/apache/polaris/pull/1804
.
--EM
--
Robert Stupp
@snazy
--
Robert Stupp
@snazy
ease/1.0.x" for
the 1.0 release. I will delete "1.0.x" a bit later.
Yufei
On Thu, Jun 12, 2025 at 9:05 AM Robert Stupp wrote:
Not sure whether everybody followed how the releases were crafted. We
discussed the branch naming pattern before during community sync calls.
There's
lists.apache.org/thread/nfp40hmwryybznxtgffvy4c5l5kk19ho>.
Schema can be found on this Google Doc - please feel free to comment
directly on the document and we can discuss in the comments section as
well:
https://docs.google.com/document/d/1AxaXy-DXE2g6rmFktA2foDI7k2zIjFzTKmI5mZnUjOs/edit?usp=sharing
Best,
Adna
y.
If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on the
main branch mainly about license/notice etc).
Thanks !
Regards
JB
Le jeu. 12 juin 2025 à 10:10, Robert Stupp a écrit :
Agree with Dmitri.
Having clear discussion subjects is crucial for the community to follow
the r
Welcome!
On 12.06.25 10:44, Jean-Baptiste Onofré wrote:
Hi everyone,
We are happy to announce Yun as new committer on the Apache Polaris podling.
Thanks a lot Yun for your contributions and warm welcome !
Regards
JB on behalf of the Apache Polaris PPMC
--
Robert Stupp
@snazy
on this Google Doc - please feel free to comment
directly on the document and we can discuss in the comments section as
well:
https://www.google.com/url?q=https://docs.google.com/document/d/1AxaXy-DXE2g6rmFktA2foDI7k2zIjFzTKmI5mZnUjOs/edit?usp%3Dsharing&source=gmail-imap&ust=175002856900&usg=AOvVaw38W8LTWpVceP8bFhLVV_La
Best,
Adnan Hemani
--
Robert Stupp
@snazy
security context
commit 1a6b3eb3963355f78c5ca916cc1d66ecd1493092 (github/public-release)
Author: Robert Stupp
AuthorDate: Tue Jul 30 13:38:08 2024 +0200
Commit: Michael Collado
CommitDate: Tue Jul 30 07:30:21 2024 -0700
Spotless, license header, add
ei
On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard
wrote:
+1 to making 801 a blocker.
Based on Alex's comments in 1799, it looks like the rotation is only
happening in JdbcMetastoreManagerFactory? If so, I think we have a
very
simple fix in PR#1804 <https://github.com/apache/polaris/pull/1804>.
--EM
--
Robert Stupp
@snazy
1 - 100 of 196 matches
Mail list logo
