I asked AI and did a quick scan of the git repo. 1. We are likely required to file the IP clearance form in svn (xml file) 2. I don't remember how the original code dump was imported to ASF repo. Did we already receive a Software Grant document from original author? 3. The git repo lacks LICENSE and NOTICE files at the root of the repo. See https://www.apache.org/legal/release-policy.html#licensing-documentation 4. The LICENSE and NOTICE files must also be copied into each JRA file's META-INF folder, see same chapter of the release-policy
Jan > 4. juni 2026 kl. 19:35 skrev Jan Høydahl <[email protected]>: > > I think there might be a requirement for a self-contained src tarball that is > self contained including build scripts, LICENSE, NOTICE files etc in order to > download, understand what it does, build the tool etc. > So yes I think we need a re-spin. > > Why don't you embrace an RC model also for MCP, i.e. Release 1.0.0 RC1, RC2 > etc? Does not ATR support that? > > As I said, I think it would be beneficial with instructions to devs on how to > test the release artifacts duringa VOTE, more than just checking SHA's. It > could be a step by step instruction, or it could be a smoke-test script. I > prefer the latter. > > Wrt binary release, that is not a requirement of the ASF, it's for > convenience only. Right now the only binary is the fat jar file. While it may > be legal, I'd prefer it to be a tgz file with a LICENSE, NOTICE, README > inside as well as the jar file. At a minimum. I don't think there's a need > for start scripts here, at least not for the stdio mode. For the http server > mode the binary distro could benefit from something more perhaps, dunno. > Guess most folks witll use the docker image to host the http version. > > Speaking of Docker: Do we want to vote on the Dockerfile source as well, and > include instructions on how to build Docker image from src tarball and test > it? > > Final question: This code donation was developed outside ASF and brought in > as a complete code grant. But we never filed an IP-clearance form to the > incubator, did we? https://incubator.apache.org/ip-clearance/ I know about > this form thorugh research for solr-orbit, but I did not know about it > earlier when MCP codebase was brought in. Should we fill and file the form > before the first release? > > Jan > >> 4. juni 2026 kl. 14:13 skrev Eric Pugh <[email protected]>: >> >> Regarding the lack of source files... I suspect that means this is NOT a >> valid release package. >> >> This is my first time ever trying to be "Release Manager" for anything at >> Apache, and I think I was leaning to much into the Apache Trusted Release >> tool to make up for my lack of knowledge in this space. ATR validates your >> release package in various ways. >> >> I just logged in (https://release-test.apache.org/checks/solr-mcp/1.0.0) and >> it does label the file solr-mcp-1.0.0-sources.jar as a "src". >> https://release-test.apache.org/report/solr-mcp/1.0.0/solr-mcp-1.0.0-sources.jar >> says: "solr-mcp-1.0.0-sources.jar: Path structure and naming conventions >> conform to policy". >> >> I then downloaded it, and realized that I think what you are suggesting is >> that what we mean by src.tgz is a bundled up version of all the code that >> was used to build the artifacts. In this case, it should be >> https://github.com/apache/solr-mcp/tree/branch_1_0_0 ? >> >> I can ping the ATR folks about if there is a weakness in the tool that >> should have flagged this as standard ASF policy! >> >> Do you think this means we need to redo this release process. And thoughts >> on what that means? Last time I deleted the 1.0.0 release in ATR, and then >> started over, which I could do on this as well. >> >> I am trackign this feedback in >> https://github.com/apache/solr-mcp/issues/15#issuecomment-4613210696 as >> clearly we need to harden the release process. >> >> Eric >> >> >> >> >> On 2026/06/03 21:28:47 Aditya Parikh wrote: >>> Regarding skills vs MCP, linking the readme to an FAQ page answering >>> that question and raising a PR. >>> >>> >>> Thanks, >>> Aditya >>> >>> On Wed, Jun 3, 2026 at 6:28 AM Aditya Parikh <[email protected]> >>> wrote: >>> >>>> To use the released jar instead of building from source follow the same >>>> steps to add path to the downloaded solr-mcp-1.0.0.jar in the config. >>>> >>>> Instructions for Claude code are in >>>> https://github.com/apache/solr-mcp README >>>> As well as will be available when this PR >>>> https://github.com/apache/solr-site/pull/175/files >>>> (content/pages/mcp/clients/claude-code.md) >>>> gets merged. >>>> >>>> claude mcp add --transport stdio -e SOLR_URL=http://localhost:8983/solr/ >>>> solr-mcp -- java -jar /absolute/path/to/solr-mcp-1.0.0.jar >>>> >>>> Please let us know if there are difficulties and we can address them as >>>> well as refine the documentation. >>>> >>>> Thanks, >>>> Aditya >>>> >>>> On Wed, Jun 3, 2026 at 3:33 AM Jan Høydahl <[email protected]> wrote: >>>> >>>>> Way off topic to discuss the existence of the project itself in this >>>>> context, I have >>>>> clients looking very much forward to adding Solr MCP to their tool belt. >>>>> >>>>> What we are discussing is how to improve the *release process* to make >>>>> sure >>>>> we vote on the actual artifacts and not something else, and perhpas >>>>> identify the >>>>> need for a "smoke tester" script , like we have for both Solr and Solr >>>>> Operator. >>>>> That would lower the bar for both committers and others to participate in >>>>> VOTEs. >>>>> >>>>> Please don't take this as critisism from my side, we're in this together >>>>> and I lift >>>>> issues with the goal of process improvement in mind. >>>>> >>>>> I have another question. The release artifacts are only jar files >>>>> >>>>> solr-mcp-1.0.0-javadoc.jar >>>>> solr-mcp-1.0.0-javadoc.jar.asc >>>>> solr-mcp-1.0.0-javadoc.jar.sha512 >>>>> solr-mcp-1.0.0-plain.jar >>>>> solr-mcp-1.0.0-plain.jar.asc >>>>> solr-mcp-1.0.0-plain.jar.sha512 >>>>> solr-mcp-1.0.0-sources.jar >>>>> solr-mcp-1.0.0-sources.jar.asc >>>>> solr-mcp-1.0.0-sources.jar.sha512 >>>>> solr-mcp-1.0.0.jar >>>>> solr-mcp-1.0.0.jar.asc >>>>> solr-mcp-1.0.0.jar.sha512 >>>>> >>>>> Would not any ASF release need to release the entire source tree as a >>>>> src.tgz >>>>> so that anyone can download it in 10 years and build the binaries from >>>>> source? >>>>> I can see that the execuable jar is more self contained and all you need >>>>> to run the mcp... >>>>> >>>>> Jan >>>>> >>>>>> 3. juni 2026 kl. 06:33 skrev Mark Miller <[email protected]>: >>>>>> >>>>>> Personally, I just see it as one more release vote we don't need. How >>>>> many >>>>>> Solr MCPs exist already? A dozen? >>>>>> >>>>>> Meh. I wouldn't use any of them anyway. It makes a much better Skill. >>>>> MCPs >>>>>> take up a crap load of context whether the current prompt uses it or >>>>> not, >>>>>> if you launch any agents, that silly token cost multiplies and context >>>>> rot >>>>>> extends out like a virus. As a simple skill, all of that is resolved, >>>>> and >>>>>> because command line usage is well burrowed into the training data, >>>>> LLM’s >>>>>> are much better at using Solr that way than via an MCP - and heck, that >>>>>> also means you hardly even need much of a skill definition given how >>>>> well >>>>>> they know the Solr apis. >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
