[drew]

Summary

Propose splitting OpenShell into a smaller core and focused repositories so new maintainers can own platforms, packaging, SDKs, and provider integrations. Keep RFC 0019 short and conversational for early discussion.

Related Issue

Closes #4425

Changes

• Define the proposed repository responsibilities and ownership expectations.
• Outline an incremental migration, risks, and alternatives.
• Leave macOS isolation, microVM placement, host process assembly, and cross-repository compatibility as open questions.

Testing

• Markdown lint passes (mise exec -- markdownlint-cli2 rfc/0019-repository-migration/README.md).
• git diff --check passes.
• Unit and E2E tests are not applicable to this RFC-only change.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture documentation updates are not applicable to this draft proposal.

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[politerealism]

Simon pointed me here from #3510 (Fedora packaging), so a few notes from that work on where the packaging line might fall. Take these as ideas.

It might help to separate two kinds of packaging, because they couple to core very differently:

• Repackaging published binaries (what openshell.spec does today via OPENSHELL_PREBUILT_BINARIES_DIR, and what install.sh does). This is loosely coupled to core: it needs a tag and the release artifacts.
• Building from source in a distro's infrastructure (Fedora's Koji builds offline from source). This is tightly coupled. feat: package OpenShell for Fedora #3510 found several build-time contracts that currently live in core: the Rust toolchain pin and vendored dependencies, whether the build honors PROTOC instead of the bundled compiler (fix(build): honor PROTOC when generating protobuf code #4441), the Python proto stub generation (fix(rpm): build the Python SDK from older protoc and install every SDK module #4439), the Z3 bindings tied to z3-sys (feat: unbundle Z3 from gateway runtime packaging #1969), and static-PIE linking for the supervisor and sandbox binaries.

Oliver raised the lockstep concern on #4244: distro packaging needs build flags, dependencies and toolchain versions kept in sync with core. One way to keep a separate packages repo honest might be for core to document a small source-build contract (supported features, environment variables, minimum toolchain, expected outputs) and to run a cheap from-source smoke build in its own CI, so drift shows up in core before it reaches a packaging repo. That could also keep the option open of leaving the from-source recipes with core while openshell-packages owns publishing and installation.

[drew]

One way to keep a separate packages repo honest might be for core to document a small source-build contract (supported features, environment variables, minimum toolchain, expected outputs)

That makes sense to me. Are there other examples of projects doing this?

[...] and to run a cheap from-source smoke build in its own CI, so drift shows up in core before it reaches a packaging repo

Hopefully we could use the same build recipe for the core and the package repos, so core would always be the source of truth from a build recipe perspective.