Thanx Tanishq for driving this initiative. Really appreciate it!!!! Unless this requires independent releases, I would prefer to keep it in our main Hive repository, as that would reduce the release and maintenance burden. Just make sure we don't introduce any dependencies or other components that could lead to legal issues.
Regarding the implementation, I share Stamatis's thoughts. I'm happy with whichever approach you prefer. If there are no strong objections by EOW, feel free to proceed, and we can continue improving it iteratively. Looking forward to your PR. Good luck!!! -Ayush On Tue, 15 Sept 2026 at 15:31, Stamatis Zampetakis <[email protected]> wrote: > > Great initiative Tanishq, thanks for driving this! > > It's not always easy to get the perfect design right from the beginning > before having actual feedback from the users. The two questions are important > but we shouldn't overthink them. > > As every new API/component it may not be production ready from day one. A > reasonable path forward is to pick one direction, mark the component/API > experimental, document all potential caveats/gaps, and then once the first > use cases are established we can refine our decision if necessary. This is to > say that I feel comfortable letting Tanishq lead the initiative and make the > final decision. If others feel strongly about one direction or the other then > please let Tanishq know as soon as possible to avoid any potential -1 > comments during the code review. > > Regarding code placement, we can be flexible as well but it may be a bit > premature to make a decision now since we don't have any idea on how the > actual implementation looks like. I don't even know if we are talking about > maven + Java code or something completely different. By default, everything > goes to the main Apache Hive repo except stuff that is bad for version > control, or not meant to be part of the release cycle. > > Best, > Stamatis > > On Fri, Aug 28, 2026 at 8:45 AM Tanishq Chugh <[email protected]> > wrote: >> >> Hi, >> >> Thank you all for the great feedback and valuable insights on this proposal. >> >> I see that we are inclined to store the MCP code in the Apache/Hive >> Repository itself, and I stand by it too, as it ensures the MCP remains in >> sync with new Hive changes and advancements, and it also aligns with release >> packaging. >> >> However, we have mixed valuable insights regarding whether to proceed with a >> single unified MCP or separate HS2 / HMS MCPs. I acknowledge the fact that >> HMS is used standalone with other engines and having an MCP server just for >> HMS can indeed serve a larger audience. To support this use case, I >> initially envisioned the unified MCP as a config-controlled plug-as-per-use >> design, allowing it to run only to serve Metadata (from the Iceberg REST >> Catalog and/or HMS Thrift APIs) if needed. >> >> In my opinion, having separate MCPs adds to the fixed infrastructure costs >> and deployment/maintenance overhead at the user end. However, I also >> acknowledge that Separate MCPs can be more Fault Tolerant. >> >> Considering all these pointers in the thread, we still need to lock in which >> approach to take. I am not completely biased towards a unified MCP, and >> given the strong valuable points raised in favor of decoupling, I would >> appreciate further discussion to help us settle on the best design, as our >> aim is to develop and deliver a product that provides the most value and >> usability to the end-user :) >> >> Thanks! >> >> Best, >> Tanishq Chugh
