I don’t think the Java code is ever a concern. Contributors will more likely be comfortable following the upstream conventions, even if their private downstream setup differs.
Yufei On Tue, Dec 2, 2025 at 4:31 PM Dmitri Bourlatchkov <[email protected]> wrote: > Thanks for your thoughts, Yufei! > > What you wrote resonates with me. > > I'd like to clarify, though, whether your points apply only to > configuration or to java code as well. WDYT? > > Thanks, > Dmitri. > > On Tue, Dec 2, 2025 at 4:06 PM Yufei Gu <[email protected]> wrote: > > > Thanks Dmitri for the detailed context. I want to offer a different > > perspective. > > > > While I understand the desire to avoid churn for a private downstream > > deployment, I’m concerned that merging the PR as-is purely to > accommodate a > > non-OSS downstream project sets a precedent that is risky for Polaris. If > > we adopt this pattern, any private downstream project could effectively > > promote its internal configuration choices into upstream simply by > > upstreaming code without aligning to Polaris conventions first. > > > > For the long-term health of the project, I think we need to maintain > > consistency and avoid creating special cases that diverge from > established > > user-faced conventions(e.g., config naming patterns here). The upstream > > should remain the place where common conventions are defined, not the > place > > where downstream decisions dictate upstream behavior. > > > > To avoid blocking this PR while still maintaining our standards, one > > possible approach is: > > 1. Align the config names now to the Polaris conventions, as reviewers > > requested. > > 2. Let the downstream project map or override its own existing config > names > > suggested by Eric. > > > > This keeps Polaris consistent, avoids setting an undesirable precedent, > and > > still gives the downstream project a clear migration path without > requiring > > OSS to inherit private naming decisions. > > > > Just my two cents. Happy to discuss further. > > > > Yufei > > > > > > On Thu, Nov 27, 2025 at 5:12 PM Eric Maynard <[email protected]> > > wrote: > > > > > I see. By extending the configuration store, I believe that project > > should > > > be able to quite easily map between its own configs and the ones that > > > eventually get merged in Polaris. Or to add its own configs. > > > > > > On Thu, Nov 27, 2025 at 5:04 PM Dmitri Bourlatchkov <[email protected]> > > > wrote: > > > > > > > Hi Eric, > > > > > > > > This situation here is that some code moves from a private downstream > > > > project to Polaris. Some of the related config names are already in > use > > > > downstream. > > > > > > > > Cheers, > > > > Dmitri. > > > > > > > > On Thu, Nov 27, 2025 at 7:35 PM Eric Maynard < > [email protected] > > > > > > > wrote: > > > > > > > > > I read through the PR, but I’m a little confused what the > dependency > > in > > > > > question is here. Surely, the project should be mindful not to > break > > > > > downstream dependencies of Polaris. But it sounds like the > contention > > > > here > > > > > is around a dependency on unmerged code? > > > > > > > > > > If this is the case, that deployment is not depending on Polaris. > In > > my > > > > > view if it depends on particular configs not present in OSS > Polaris, > > > > > it would be best served by taking advantage of some of the > mechanisms > > > > > available for adding custom configs on top of the ones in OSS > > Polaris. > > > > > > > > > > —EM > > > > > > > > > > On Thu, Nov 27, 2025 at 10:53 AM Dmitri Bourlatchkov < > > [email protected] > > > > > > > > > wrote: > > > > > > > > > > > Hi All, > > > > > > > > > > > > This discussion stems from PR [3135], where having particular > > config > > > > > names > > > > > > was flagged as a concern [1]. > > > > > > > > > > > > While I agree that aligning configuration names across all > Polaris > > > code > > > > > > modules is a worthy goal, in this particular case it is > complicated > > > by > > > > > > downstream dependencies that already exist on those config names. > > > > > > > > > > > > The NoSQL code contributed in this PR is already in use in > private > > > > > > environments. At the same time it is being contributed to Polaris > > in > > > > the > > > > > > hole that it would be beneficial to a wide community. > > > > > > > > > > > > Making the requested config changes up front would complicate > > > > > > re-integration of the contributed code from Polaris `main` into > > > > existing > > > > > > downstream projects. > > > > > > > > > > > > Therefore, I ask the community to allow the existing config names > > to > > > be > > > > > > merged. > > > > > > > > > > > > If there are strong concerns about the existing config names, I > > > propose > > > > > to > > > > > > open GH issues for them and address later when backward > > compatibility > > > > can > > > > > > be handled in OSS code for all use cases. This can probably be > done > > > > after > > > > > > some reasonable delay to allow us to first re-integrate the code > > from > > > > > > `main` downstream. > > > > > > > > > > > > Note that addressing config renames with backward compatibility > > > > directly > > > > > in > > > > > > [3135] would complicate the code and make reviewing it harder. > The > > > > > current > > > > > > PR reflects the code that has already been put to practice. > > > > > > > > > > > > We have an existing situation where a downstream project's > > > requirements > > > > > for > > > > > > keeping `polaris-code` java compatibility at version 11 are > > respected > > > > [2] > > > > > > despite having no reasons for holding that module's java version > > back > > > > > from > > > > > > the perspective of binary Polaris Server distributions. > > > > > > > > > > > > In general, I believe it is important for the success of the > > project > > > to > > > > > > take downstream builds into consideration as well as users of the > > > > binary > > > > > > distribution. > > > > > > > > > > > > Please share your thoughts on this matter. > > > > > > > > > > > > [1] > > > https://github.com/apache/polaris/pull/3135#discussion_r2558515915 > > > > > > > > > > > > [2] > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/polaris/discussions/100#discussioncomment-10267097 > > > > > > > > > > > > [3135] https://github.com/apache/polaris/pull/3135 > > > > > > > > > > > > Thanks, > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > >
