adityamparikh opened a new issue, #181: URL: https://github.com/apache/solr-mcp/issues/181
All the open PRs authored by me are now rebased on `main` (`a84033b`) and individually green. But they are **not independently mergeable** — several touch the same files, so merging them in an arbitrary order stalls on conflicts roughly every second merge. This issue records an order that has been **empirically verified**, not reasoned about: I replayed candidate orders as real merges onto `a84033b` and measured which conflicted. ## The overlap that causes it | File | PRs competing for it | |---|---| | `CollectionService.java` | #103, #108, #110, #111 | | `SchemaService.java` | #98, #108, #110 | | `SearchService.java` | #108, #110, #164 | | `IndexingService.java` | #108, #110 | | `build.gradle.kts` | #104, #35, #136 | #108 (collection-name validation) and #110 (SLF4J logging) are the hubs — between them they touch all four service classes. ## Recommended order Merging in this sequence, **13 of these merge with zero conflicts**: | # | PR | Area | |---|---|---| | 1 | #175 | `JsonResponseParser` — empty-facet fix | | 2 | #99 | `SearchResponse` | | 3 | #104 | `solr.url` validation | | 4 | #105 | document-creator blank input | | 5 | #162 | MCP server instructions | | 6 | #174 | release workflow fixes | | 7 | #143 | docs site *(still blocked on the dev@ discussion — skip if unresolved; it conflicts with nothing)* | | 8 | #53 | spec doc *(draft)* | | 9 | #111 | narrow metrics catch clauses | | 10 | #103 | `CollectionService` visibility | | 11 | #164 | typed `SortClause` | | 12 | #108 | unified collection-name validation | | 13 | #136 | cut 1.0.0 *(per @epugh, this goes to `branch_1_0_0`, not `main`)* | **Verified:** with those 13 merged together, `./gradlew build` is green on JDK 25 — **415 tests, 0 failures, 7 skipped**. So the sequence is not just conflict-free, it is semantically consistent. ## The two that need a rebase, and why - **#110 (SLF4J logging)** — conflicts on `CollectionService` + `SearchService` whatever the order. It adds logging *inside* the same catch blocks #108 and #111 modify, so it is inherently last-mover. I'll rebase it once #108 lands. - **#98 (`getSchema` throws clause)** — conflicts with #108 on `SchemaService`. Six lines; trivial rebase. One of #98/#108 must move, and #108 is the larger change, so #98 is the cheaper one to rebase. Ordering alternatives I measured, for the record: | Order | Clean | Needed rebase | |---|---|---| | **Recommended (above)** | **13** | #110, #98 | | Isolated first, hubs last | 13 | #108, #110 | | Hubs (#108, #110) first | 12 | #98, #111, #164 | | #110 before the singles | 12 | #111, #164, #98 | Two rebases appears to be the floor — #110 and one of #98/#108 conflict pairwise no matter what. ## Separately: #35 vs #136 These collide **by design** and it is not an ordering problem. Both rewrite the same line in `build.gradle.kts`: #136 pins `version = "1.0.0"`, #35 replaces it with `version = semver.version` (git-semver-plugin). Manual pin vs. automatic derivation — whichever lands second needs a deliberate re-resolve, not a mechanical rebase. Per the discussion on #35, the plan is 1.0.0 first, tag it as the semver baseline, then #35. #35 is in any case parked behind getting one real release out. ## Not in this list - **#23** (Spring Boot 4 / Spring AI 2.0) — parked behind the 1.0 release; rebased and green (372 tests) but deliberately out of the queue. - **#86**, **#144**, **#159** — other contributors'. #144 and #159 are waiting on merge PRs I opened against their forks (shahzadarain/solr-mcp#3, y-luis-rojo/solr-mcp#2). Happy to do the #110 and #98 rebases as soon as their predecessors land — just ping me, or they can be done in a batch at the end. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
