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
Good point Russell. Do we have a list of talks since last 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 reporting
Yes, it's what I meant: better to have discussion/consensus on design
doc or dev mailing list before PR.
Generally speaking, the vote should be used only to confirm on one
thing (we should not vote between A and B, but more ok with A, +1 or
-1).
So, I would propose to follow the good practices and
The binary distributions are everything we distribute/publish. I would
focus on archive (tar.gz/zip), and jar files.
As we have a Polaris repo on Docker HUB, I will also include docker image check.
Regards
JB
On Fri, Mar 14, 2025 at 1:53 PM Dmitri Bourlatchkov wrote:
>
> I think it's a good idea
Fully agree Russell. That's the plan :)
Thanks !
Regards
JB
On Fri, Mar 14, 2025 at 4:37 PM Russell Spitzer
wrote:
>
> 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 agree in principle, but I do think the wording in the contribution
guidelines that JB shared is the better approach: discuss and approve on
the dev list *before* you have a PR ready for review. Otherwise if there
are major objections to the directional approach, you've spent a bunch of
time writi
> As we have a Polaris repo on Docker HUB [...]
What do we currently push there?
Thanks,
Dmitri.
On Fri, Mar 14, 2025 at 3:47 PM Jean-Baptiste Onofré
wrote:
> The binary distributions are everything we distribute/publish. I would
> focus on archive (tar.gz/zip), and jar files.
> As we have a P
I agree that a simple docker pull is a huge advantage to users.
However, in that case we should probably promote the Dockerfile to a normal
production artifact (it is currently under /regtests and has test-specific
code).
Cheers,
Dmitri.
On Fri, Mar 14, 2025 at 4:37 PM Alex Dutra
wrote:
> Hi J
Hi Dmitri,
The Dockerfile under /regtests is not the official Polaris Dockerfile, it's
used only for regression tests and contains a Spark runtime and the tests.
We could publish it as well, but imho it's not a must.
The official Dockerfile for the Polaris server is here:
https://github.com/apac
Thanks for the pointer, Alex :)
On Fri, Mar 14, 2025 at 5:38 PM Alex Dutra
wrote:
> Hi Dmitri,
>
> The Dockerfile under /regtests is not the official Polaris Dockerfile, it's
> used only for regression tests and contains a Spark runtime and the tests.
> We could publish it as well, but imho it's
Hi Dmitri
https://hub.docker.com/r/apache/polaris
It's empty for now :)
Regards
JB
On Fri, Mar 14, 2025 at 8:56 PM Dmitri Bourlatchkov wrote:
>
> > As we have a Polaris repo on Docker HUB [...]
>
> What do we currently push there?
>
> Thanks,
> Dmitri.
>
> On Fri, Mar 14, 2025 at 3:47 PM Jean-
I think it's a good idea. Thanks JB.
If it's only for testing binary distributions. Can we base it on 0.9.0 so
that we can give users a clear message that everything else is the same as
0.9.0 except it provides binary distribution?
This is mainly to make life easier for OSS users as well as develo
+1 for what Tyler said. In general, votes should be used to confirm
agreement, not to choose a direction.
On Fri, Mar 14, 2025 at 9:19 AM Tyler Akidau wrote:
> I agree in principle, but I do think the wording in the contribution
> guidelines that JB shared is the better approach: discuss and app
Hi folks,
We are working on the 1.0.0 release, with a lot of new features and fixes.
One important change between 0.9.0 and 1.0.0 is the publication of the
binary distributions, with all related requirements (LICENSE/NOTICE,
etc).
I'm working on the LICENSE/NOTICE and binary distributions publica
Hi Dmitri
Thanks for starting this discussion.
I thought we already agreed on that. If we take a look on
https://polaris.apache.org/community/contributing-guidelines/ we can
see in the good practices section (first bullet point):
"Change of public interface (or more generally speaking Polaris
ex
+1
On 03.03.25 20:14, Dmitri Bourlatchkov wrote:
Thanks JB!
The report looks good to me.
Cheers,
Dmitri.
On Mon, Mar 3, 2025 at 4:55 AM Jean-Baptiste Onofré wrote:
Hi folks,
I prepared the Polaris report for March 25 here:
https://cwiki.apache.org/confluence/display/INCUBATOR/March2025
C
API changes which were not explicitly discussed are the PRs 1150 [1] and
808 [2].
PR 808 has been merged w/o addressing all concerns about the hard
dependencies of Polaris APIs on Iceberg-owned APIs have been raised
multiple times. The same concern applies to 1150. It's been raised
multiple t
+1
on Dmitri's proposal
On 14.03.25 07:52, Jean-Baptiste Onofré wrote:
Hi Dmitri
Thanks for starting this discussion.
I thought we already agreed on that. If we take a look on
https://polaris.apache.org/community/contributing-guidelines/ we can
see in the good practices section (first bullet
Hi JB,
That's a very good idea.
Regarding Docker images, I think it would be great if users could just
"docker pull apache/polaris" and start using Polaris, as opposed to having
to manually build the images.
However, a Docker image with just in-memory persistence is likely useless
for anything e
Hi Yufei
That's a good point.
What about doing both ?
- 0.9.1 would be the same as 0.9.0 but with binary distributions
- 0.10.0 would be based on main
The reason I would like to do that is because the binary distributions
are not the same (the framework used is not the same).
In order to "prepar
22 matches
Mail list logo
