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 times in design docs and on the dev-ML (e.g. [3]).
We have established the "Contributing Guidelines" [4] as a project for
the whole project, it's been reminded of multiple times on the community
sync and the dev ML [5].
[1] https://github.com/apache/polaris/pull/1150
[2] https://github.com/apache/polaris/pull/808
[3] https://lists.apache.org/thread/1fqocs00pno0xfr4ss2p69d6dv5h8qzf
[4] https://lists.apache.org/thread/bcnh1dwgoxd2dvtqk6z935gfzmh4q0jq
[5] https://lists.apache.org/thread/hb80odvpn05sodh0nvhnnsqbyrmltbwr
On 14.03.25 09:11, Robert Stupp wrote:
+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 point):
"Change of public interface (or more generally speaking Polaris
extension point) should be discussed and approved on the dev mailing
list. The discussion on the dev mailing list should happen before
having a “ready-for-review” Pull Request."
My view on it also covers REST API changes, as client-facing APIs.
So, I agree with your proposal, I thought it was clearly stated to the
community, but it seems not :)
Regards
JB
On Fri, Mar 14, 2025 at 1:56 AM Dmitri Bourlatchkov
<di...@apache.org> wrote:
Hi All,
A lot of REST API changes have been happening lately in GitHub.
Client-facing APIs changes are relatively a lot more important than
refactorings and other code fixes, but can easily be hidden from
view in
the multitude of GH notifications.
Therefore, I propose to run votes on the dev list for REST API changes
after the initial review on the PR.
WDYT?
Thanks,
Dmitri.
--
Robert Stupp
@snazy
