I agree with Russell 100%. I think the intent here is to codify a spirit of
collaboration. That’s always going to be imperfect. But clarifying
expectations is important, even if it’s imperfect.
For some of the requirements (e.g., waiting an appropriate period or
waiting merging with unresolved com
> It is possible for some Polaris APIs to be developed first to unblock
support of certain use cases, and later contributed back to the IRC spec,
depending on the appetite of both communities.
This was exactly the intention with the notification API. It was never
expected to live long-term in the
Thanks, Jack, for bringing this up! I think separating the Iceberg REST
APIs from the other Polaris REST APIs is an excellent idea. Not only does
it simplify any potential future rebases of the Iceberg REST spec, but it
also provides developers with a clearer distinction between the different
sets
Hi everyone,
I am starting to work on Polaris related tasks, and realize that currently
the state of the spec folder [1] in the project is a bit disorganized:
The Iceberg REST catalog (IRC) spec [2] contains non-standard APIs like the
/notifications API, but misses a few APIs like the scan planni
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
Hey,
I'm generally in favor of these things. But I find it quite difficult to
put all that into a guideline/rules/bylaws and be sure that everybody
understands it in the exact same way as it is meant. In practice there
are also often situations that could not be resolved with such rules,
wors
On Wed, Jan 22, 2025 at 12:58 PM Jean-Baptiste Onofré
wrote:
> It's not a problem to have several people working on the same feature.
>
> By duplicate PRs, I mean that you open a PR, where you get comments,
> changes requested, etc. Then, you close this PR to open a new one (on
> the same topic).
Hi Dmitri
It's not a problem to have several people working on the same feature.
By duplicate PRs, I mean that you open a PR, where you get comments,
changes requested, etc. Then, you close this PR to open a new one (on
the same topic). So, I mean by a single person. I'm more in favor of
refactor
Hi JB,
What do you mean by "No duplicated PRs is allowed (in order to keep history
and comments)"?
Maybe a terminology gap on my part :) but what is a "duplicated PR"?
Do you mean multiple people working on the same feature? Or people
submitting multiple PRs with alternative implementations?
Ho
Hi All,
For visibility: PR#610 (docker changes) [1] has some "request changes"
comments.
It looks like they got addressed. If there are still concerns, please
comment again.
Thanks,
Dmitri.
[1] https://github.com/apache/polaris/pull/610
Hi folks,
Thanks to your feedback and comments (in PRs, this thread, and the
other one regarding main branch stability), I'm updating the proposal
as follow:
* Changes on public interfaces/extension points (potentially used by
parties) should be discussed and approved on the dev mailing list (a
vo
Hi folks,
Following the NOTICE/LICENSE fix and the issue found on
TestPolarisVersion in rc3, we fixed the test compilation issue.
This is the vote for Apache Polaris 0.9.0-incubating rc4.
* This corresponds to the tag: apache-polaris-0.9.0-incubating-rc4
* https://github.com/apache/polaris/tree/
12 matches
Mail list logo
