As discussed in the community sync today, I opened PR [1890] to inform
users about what to expect in terms of backward compatibility as the
project evolves.
I proactively marked it as 1.0 blocker because I'm not sure whether docs
have to be merged before the release in order to be reflected in the
I have no objections. Any of my old branches are there purely accidentally.
Mike
On Thu, Jun 12, 2025 at 1:48 PM Yufei Gu wrote:
> +1, I'm all for keeping the code base and repo clean. Deleted
> branch yufei-test-1.0.x and 1.0.x. I think we can also delete
> branch "release/0.10.x" as the 0.10
I've marked [1889] as a 1.0 blocker. Feel free to disagree :) My rationale:
Polaris 1.0 is a binary release and will provide a platform for users to
experiment with Generic Tables. It is important to set correct expectations
about this feature in terms of functional scope, level of maturity, plans
Re: the server module rename [1695]:
I see that the 1.0 blocker label was removed from it. I'm personally ok
with not including it in 1.0.0.
However, I'd prefer to include it if other people find it valuable too. My
rationale:
* The new module names are more natural and probably more intuitive t
>From my POV the "release/a.b.c" pattern for release branches is
self-explanatory and has prior history in Polaris.
If the release guilde is perceived as too vague on this topic, let's update
the guide and keep the pattern.
In that regard, we may want to discuss whether to use very versions
speci
Welcome, Yun!
Cheers,
Dmitri.
On Thu, Jun 12, 2025 at 4:45 AM 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 Pol
Thanks for all the replies. Since I opened the topic of specification , let
me come with a proposal that I'm looking forward to iterate upon with the
help of the community
Laurent
On Wed, Jun 11, 2025 at 4:12 PM yun zou wrote:
> Yes. I think we have agreed that we will make sure things are desc
Delete the branch "1.0.x".
I'm OK with the name "release/1.0.x", but I don't think the current release
guideline[1] mentioned any mandatory branch name convention. 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/
+1, I'm all for keeping the code base and repo clean. Deleted
branch yufei-test-1.0.x and 1.0.x. I think we can also delete
branch "release/0.10.x" as the 0.10 release was cancelled.
Yufei
On Thu, Jun 12, 2025 at 8:30 AM Jean-Baptiste Onofré
wrote:
> Hi
>
> I deleted my "old" branches. Sorry a
Thanks a lot for the contribution! Well deserved!
Yufei
On Thu, Jun 12, 2025 at 4:10 AM Ajantha Bhat wrote:
> Congratulations Yun.
>
> On Thu, Jun 12, 2025 at 4:31 PM Alex Dutra
> wrote:
>
> > Congratulations Yun! Glad to have you on board!
> >
> > Alex
> >
> > On Thu, Jun 12, 2025 at 10:45 A
Heads up: It's also documented in the release-guide via
https://github.com/apache/polaris/pull/1539, not sure you saw it. That
doc also mentions how to apply versions, create tags etc.
On 12.06.25 19:41, Yufei Gu wrote:
Thanks for the explanation. Created a new branch named "release/1.0.x" for
Thanks for the explanation. Created a new branch named "release/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 patte
The issue I see is that the proposal is not finalized. And without that
we do not know the keys and most importantly the query patterns. Without
that information it's not possible to design an efficient data model.
As mentioned during the community sync, a working prototype in a
draft-PR is ve
The Polaris event listener framework is not necessarily 1:1 to the Iceberg
Events API -- IIRC, it actually predated the Iceberg Events API proposal. I
think the pieces of code that just involve persisting Polaris events
somewhere may not need to block on the Iceberg API changes to retrieve
Iceberg
Not sure whether everybody followed how the releases were crafted. We
discussed the branch naming pattern before during community sync calls.
There's also the draft PR 485 for semi-automatic releases that relies on
the same naming pattern. To change that, we have to have a discussion on
dev@ fi
Not sure I follow you (maybe you didn't reply to my message specifically :)).
My proposal was just to call for 1.0 consensus. Are we good in what
should be included ?
About #1695, if no consensus, I'm fine to remove the 1.0-blocker label
here (it was best effort, and can be done later).
Regards
We didn't do that for 0.9 and 0.10 releases before cutting a branch. If you
think that's a new process we need to follow, please open a new dev ML
thread for discussion.
the wrong branch name
Can you explain why there is a wrong branch name?
Where is this agreement recorded?
Where is the agree
Hi Adnan
Nice document ! I will do a full pass and comment.
I think it's great to have a draft PR as "implementation ref" for the
Iceberg proposal. I would just suggest keeping the PR as draft,
waiting for a consensus on the Iceberg Events API (during the last
catalog meeting, we had discussions,
Hi
I deleted my "old" branches. Sorry about 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
>
I think we should indeed keep the number of branches in the main repo to a
minimum (as Robert suggested).
Forks are probably sufficient for PRs and experimental work.
Cheers,
Dmitri.
On Thu, Jun 12, 2025 at 4:26 AM Robert Stupp wrote:
> Hi guys,
>
> I noticed that there are a bunch of stale br
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
Congratulations Yun.
On Thu, Jun 12, 2025 at 4:31 PM Alex Dutra
wrote:
> Congratulations Yun! Glad to have you on board!
>
> Alex
>
> On Thu, Jun 12, 2025 at 10:45 AM Jean-Baptiste Onofré
> wrote:
> >
> > Hi everyone,
> >
> > We are happy to announce Yun as new committer on the Apache Polaris
>
Hi folks
Back from the other part of the pond :)
I think we should have a clear consensus about
1.0 content. That’s why I invite everyone to flag issues and PRs with the
1.0-blocker label.
I propose to do a review in 24h. As soon as we don’t have any 1.0-blocker,
we are good to start rc.
We can
Congratulations Yun! Glad to have you on board!
Alex
On Thu, Jun 12, 2025 at 10:45 AM 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 b
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
Hi,
If I understand correctly, this effort is still in the "proposal state"
in Iceberg (the PR itself is still a draft). This means that nothing is
set "in stone" yet. Things can still change fundamentally, the proposal
can even be rejected.
IMHO we should wait adding code to Polaris until t
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 below).
Generally, I think only the technically necessary branches should be in
the Polaris GH repo. Those are: main, a
Agree with Dmitri.
Having clear discussion subjects is crucial for the community to follow
the right threads. I think we should only get to consensus about the
particular thread topic and nothing else.
Consensus in a community in general, at least in my opinion, is more
than two people havin
28 matches
Mail list logo
