Since the vote was cancelled and PR #4816 merged immediately afterward, I
do not think the public record should be read as consensus on the exact API
shape. I may be missing a separate consensus signal, but I think we should
follow up before release with explicit beta/Ossie wording,
endpoint-discovery cleanup, and payload-shape review.

Robert

On Thu, Jul 2, 2026 at 7:27 AM Jean-Baptiste Onofré <[email protected]> wrote:

> Hi Yufei,
>
> I agree with your suggestion. We can begin the preparatory steps to host
> Ossie models now and proceed with the integration as soon as the Ossie
> specification becomes available.
>
> Regards,
> JB
>
>
> On Tue, Jun 30, 2026 at 6:55 PM Yufei Gu <[email protected]> wrote:
>
> > JB, waiting for Ossie makes sense to me. That said, I'd suggest we work
> in
> > parallel where possible.
> >
> > From my understanding, the main dependency on Ossie is the JSON
> validator,
> > which will arrive a bit later. Most of the other work can proceed
> > independently in the meantime.
> >
> > I'm also OK moving forward without a formal vote if that's the preferred
> > approach. I would keep the API explicitly in **beta** and make it clear
> > that we intend to transition to the Ossie specification once it becomes
> > available. That gives us a path to make progress now while remaining
> > aligned with the future direction.
> >
> > Yufei
> >
> >
> > On Tue, Jun 30, 2026 at 5:38 AM Jean-Baptiste Onofré <[email protected]>
> > wrote:
> >
> > > Hi,
> > >
> > > It might be worth waiting for Apache Ossie to bootstrap before
> > proceeding.
> > > While I agree with the intent, I want to avoid duplicative work where
> we
> > > implement the OSI spec first and the Apache Ossie spec as a follow-up.
> > > Since the OSI spec is transitioning into the Ossie spec, and an initial
> > > Apache Ossie spec release is expected soon, I suggest we pause this
> vote.
> > >
> > > Additionally, I would prefer to find a consensus rather than holding a
> > > vote, as voting is typically reserved for when consensus is difficult
> to
> > > reach. This vote could likely be considered a code modification under
> > > Apache voting guidelines (
> https://www.apache.org/foundation/voting.html
> > ).
> > >
> > > My recommendation is to pause the vote for now and leverage Apache
> Ossie,
> > > which I am currently working on.
> > >
> > > Thoughts?
> > >
> > > Regards,
> > > JB
> > >
> > >
> > > On Tue, Jun 30, 2026 at 12:51 AM Yufei Gu <[email protected]>
> wrote:
> > >
> > > > Beta sounds good to me. We can clarify the beta status in a follow-up
> > doc
> > > > change.
> > > >
> > > > Yufei
> > > >
> > > >
> > > > On Mon, Jun 29, 2026 at 3:27 PM Dmitri Bourlatchkov <
> [email protected]>
> > > > wrote:
> > > >
> > > > > Hi Yufei,
> > > > >
> > > > > I'd like to understand the impact of this vote better.
> > > > >
> > > > > Are you proposing to accept this new API without first going
> through
> > a
> > > > > "beta" phase?
> > > > >
> > > > > I think the beta process is pretty standard for new APIs in Polaris
> > > these
> > > > > days (e.g. the Metrics API).
> > > > >
> > > > > Thanks,
> > > > > Dmitri.
> > > > >
> > > > > On Mon, Jun 29, 2026 at 1:38 PM Yufei Gu <[email protected]>
> > wrote:
> > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > I'd like to call a vote on accepting the OSI Semantic Model API
> > > > > > specification proposed in PR #4816(
> > > > > > https://github.com/apache/polaris/pull/4816)
> > > > > >
> > > > > > This proposal introduces the initial scaffolding for the Open
> > > Semantic
> > > > > > Interchange (OSI) Semantic Model API in Polaris. The primary goal
> > is
> > > to
> > > > > > establish the REST API surface and associated specification,
> while
> > > > > leaving
> > > > > > the implementation intentionally minimal. This provides a stable
> > > > > foundation
> > > > > > for future work while allowing the community to iterate on the
> > > > > > implementation independently.
> > > > > >
> > > > > > This vote will remain open for 72 hours. Please vote:
> > > > > >
> > > > > > [ ] +1 Accept the proposal
> > > > > > [ ] 0 No opinion
> > > > > > [ ] -1 Do not accept the proposal (please provide reasoning)
> > > > > >
> > > > > > Thanks to everyone who participated in the design discussions and
> > > > > reviews.
> > > > > > Yufei
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to