Could we please consider the first step here?

1. Move the GUI components from OpenHands/OpenHands to OpenHands/OpenHands-Web, delete related code from the main OpenHands repo, update the README to note that we are migrating repo structure, and cut at least one OSS+SaaS release to make sure our infra is ready for this repo structure.

2. Migrate all GitHub issues/PR to OpenHands/OpenHands-Web

3. Then merge OpenHands/software-agent-sdk with OpenHands/OpenHands (using merge unrelated histories to preserve contributors & commits), and move all issues/PRs

4. We will archive the

OpenHands/software-agent-sdk

repo and point it to

OpenHands/OpenHands

for future references?

Step 1 really means to make the Web repo and cut a release from there. It should be the same thing and work just the same, I think? And if not, we'll find out? cc: @quiet-night-61895 @better-park-34863 @wooden-umbrella-84098 If there are blockers, could we maybe bring them out to address them?

I think the main blocker is time and not wanting to break prod 🙂 We probably would need to come up with a plan for a date at which we'd do this switch and prepare, but I'm not sure when that date would be

Sorry to be dense, I do need to say, I don't understand the "break prod". I don't get it, because it's the same codebase.

There's just a lot of moving parts when deploying a system, like where the docker images are created from, for instance. Currently the docker images live in OpenHands/OpenHands, but if we move them they'll live in another repo. We'd have to make sure that all the configuration works properly and we don't accidentally cause the production service to break

nod Absolutely. I think that's why Xingyao was proposing to cut a release to make sure it works

Yeah these changes are always very disruptive in ways that are hard to predict. But we'll make a plan and execute

^ @wooden-umbrella-84098 I haven't seen a ticket but I think we're at the point where there's solid consensus to do it, just a question of when. Platform queue could make sense. To put some color on the logistics, the approach of just cutting a release to see if it works would be manageable for SaaS. Self-Hosted is more of a variable - it's still on V0, the runtime image is still in play. But we're making strides on that release process, and if we get this clearly in someone's court that can be sorted out.

yeah, i don’t think anyone owns it at the moment, I think Ray’s right that it’d be good for platform to own

Bumpy. Could we please make an OH-Web repo?

https://github.com/OpenHands/OpenHands-Web Engel you have write access

I understand this has been waiting for some time after we got consensus on the repo structure. Here's my understanding of where things are. • We've agreed that Platform team can own our end of this • With the V0 sunset still in progress there was concern about starting another transition • Some good news: Initially I thought changing repos would change the image address, but we can setup any repo to publish to any GHCR package so that should actually be seamless In light of that lowered impact, I'll pitch if it's feasible to we can get OH-Web started during this long tail of V0 sunset. More details on images: • These will change owning source repo, but stay in the same GHCR namespace: ◦ V0 runtime:

<http://ghcr.io/openhands/runtime|ghcr.io/openhands/runtime>

◦ V1 agent-server:

<http://ghcr.io/openhands/agent-server|ghcr.io/openhands/agent-server>

◦ enterprise-server

<http://ghcr.io/openhands/enterprise-server|ghcr.io/openhands/enterprise-server>

• OpenHands Helm chart depends on V0 runtime image hosted at

<http://ghcr.io/openhands/runtime|ghcr.io/openhands/runtime>

, because: • We still support some self-hosted users who in the process of transitioning off of V0, which we expect to be able to discontinue support of within the next couple of releases (if I've correctly recalled our convo this week, @curved-angle-80449)

@quiet-night-61895 Yes, the ghcr location doesn't depend on the source repo. 👍 It would be awesome to build a test release. Just to try and see. I think it doesn't depend on V0 either, it's worth trying the full repo build(s) like a full repo build(s)?

I also have some opinions on how we structure the frontend in this new world, I'm going to start a new thread in #C0ACTL5GAQ3

@quiet-night-61895 Yes., we have one customer still on v0 and they are have some install disruption which is causing some delay on this, but I think once we ship plug-in directory, which should happen soon, we'll be less concerned. We are in weeks not months territory.

This shouldn't affect the source repo it comes from