Thanks for the beta/Ossie cleanup in #4983. I think that is useful and should move forward.
I do not think that fully closes the API-shape follow-up from #4816, though. Before #4961 turns the semantic-model API into real CRUD behavior, I think we should still settle two things explicitly: 1. whether `semantic_model` should remain escaped JSON in a string, or whether the API should model the Ossie document as JSON; 2. whether endpoint advertisement should wait for / align with the endpoint registry work in #4926, so semantic-model discovery does not hard-code another optional non-IRC API path. 3. how clients are expected to use the API in practice while it is beta: whether clients should treat the document as opaque round-trip storage, whether Polaris intends generated clients to model the Ossie payload, and what compatibility expectations clients should have before the API becomes stable. I support keeping semantic models as beta/preparatory Ossie document hosting. I just want to avoid making the beta API sticky before the payload and discovery shape are reviewed. On Mon, Jul 6, 2026 at 8:09 PM Yufei Gu <[email protected]> wrote: > Hi folks, here is the PR to add the beta wording. Please take a look, > https://github.com/apache/polaris/pull/4983. > > Yufei > > > On Thu, Jul 2, 2026 at 11:53 PM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi Yufei, Robert, > > > > I agree regarding the release process; shipping beta features is > consistent > > with our past practices. > > > > As I noted in the PR, the beta flag appears to be missing. Given this and > > several unresolved comments, it would have been better to address the > > feedback before merging. There is no rush, and considering community > > feedback is essential. > > > > While I am very excited about the semantics feature in Polaris and > > leveraging Apache Ossie, we must proceed with community consensus rather > > than rushing. > > > > I propose that we keep the PR merged but follow up immediately to include > > the necessary beta wording and address the remaining concerns. > > > > Regards, > > JB > > > > Le jeu. 2 juil. 2026 à 21:06, Yufei Gu <[email protected]> a écrit : > > > > > Thanks, Robert. I agree that we should clarify the beta wording and > > review > > > the payload shape before considering the API stable. > > > > > > That said, I'm not sure those items need to block a release. The > > question, > > > to me, is whether we're comfortable allowing a WIP feature to evolve > > across > > > multiple releases. My understanding is that Polaris releases are not > tied > > > to any individual feature reaching completion. Instead, we release the > > > project as it stands, while features continue to mature over time. We > > > already have precedents for this. For example, Generic Tables shipped > as > > > experimental in 1.0.0 incubating and were only marked GA in 1.3.0 > > > incubating, and many other features also fit to the same pattern, like > > > event handling. > > > > > > Yufei > > > > > > > > > On Thu, Jul 2, 2026 at 10:52 AM Robert Stupp <[email protected]> wrote: > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
