The source code for the workstation product is currently hosted in a separate repository, mapped into fuchsia at //src/experiences
, and can only be built against the fuchsia buildroot. This structure allows the workstation product to use internal APIs and does not provide a clear boundary between platform and product. We should be able to develop the components that comprise the Workstation product independently from the Fuchsia platform and still assemble them into a product outside of fuchsia.git.
The workstation product is actively used by fuchsia developers and thus the development workflow needs to be iteratively updated to limit the amount of disruption felt by in-tree developers. To this end, the migration of the workstation product can be broken down into two phases. The first phase focuses on us learning how to do product builds and assembly out-of-tree without changing any of the current workflows. The second phase focuses on us untangling the workstation product from the platform's test and build story.
The initial phase will allow the PDK working group to work towards out-of-tree assembly by mimicking the way we develop the Workstation product currently but instead of mapping the experiences repo into fuchsia.git it will be mapped into a repository that has no knowledge of how to build the platform. More specific details will be included in a forthcoming RFC.
The currently thinking about how to do this would follow these steps:
workstation_session
, ermine and simple browser, off of all internal APIs. We are excluding the Terminal from this at this point since its graphic library is not ready for out of tree migration. The workstation will still be built in-tree but will only rely on the API which is in the public SDK. Note, this transition does not include any of the x64 board support or any drivers.jiri
. At this point, the workstation repository will not be buildable but will give us a place to start.The Workstation product is currently a load-bearing part of the platform development and test story. The second phase will focus on detangling this dependency and removing the Workstation entirely from the fuchsia tree. The specifics of how we are going to do this are not entirely clear but as we work them out we will submit an RFC for this phase of the project.
The current thinking is as follows but will evolve as we understand the problem more:
The decentralized product integration workflow will drive most of the work that goes into making the tooling needed available to this project. This project is a natural extension of that workflow.
The workstation team team will need to update the existing workstation components to be buildable entirely against the SDK. They will also need to change their existing workflows to move to working in an out-of-tree environment. This will most likely cause a disruption to their process as we iron out the workflows.
The session framework team will need to make the current, legacy rust libraries available as a fidl interfaces which are in the public SDK. They will need to create components which serve these interfaces instead of having the workstation session call into private libraries directly. This could come in the form of a refactor of the workstation session as well.
The Fuchsia Rust team will need to support out of tree development if we are to build the workstation session in rust. If this work cannot be done by the rust team then the workstation team will take on the work to rewrite the session in another language.
The SDK and toolchain will need to roll into the github repository so we can build the components. The process to set up the integration will be done by the workstation out-of-tree team and they will also be responsible for fixing any breakages. The only impact this will have on the SDK and toolchain team will come in helping to diagnose issues. We would like to purposely limit the amount of work required by these teams to support us so that we can use the workstation as a datapoint for scaling to other partners. As this project nears completion of phase 2 we will be in a position that we can start treating workstation more like a 1p customer which has SLAs against breaking SDK changes, however, I believe that this should be done not necessarily as a way to prevent the breakage of workstation but rather to give the SDK team a location in which they can experiment with ways to roll out changes without breaking customers in a more scalable way.
The workstation product will be built using bazel. This will take more setup time than if we were to use gn but it will allow us to build against a different build root without having to make changes to the BUILD.gn rules in fuchsia. The workstation team will be responsible for writing these build rules and maintaining them. If the fuchsia build team decides to explore using bazel in the future we can work together to try to make these available to both repositories.
For the initial phase of this project where we focus on just getting out of tree assembly working we will need help from the infrastructure team to help set up a daily builder to publish a daily snapshot of the platform. This builder will be monitored by the workstation out-of-tree team but they will likely need help from infrastructure to debug build failures.
As we move into phase 2 of the project we will need to set up continuous integration to ensure that the Workstation product does not break. This infrastructure will span across fuchsia infrastructure and open source infrastructure. The open source infrastructure will be used for running tests on femu, building release candidates, rolling in sdks/toolchain/etc. The workstation team will need to collaborate with the infrastructure team on the best approaches to do this but they should be responsible for doing the work to see what we are missing to allow non-fuchsia teams to do this. The tests that need to run on devices will need to run in fuchsia infrastructure because we will not have an open source device lab. This collaboration will look similar to the collaboration that we currently have with the flutter team which runs on our device lab.
As we start to untangle the Workstation product from the platform we will need to start moving the workstation tests that are used for platform validation into CTS. This will require collaborating with the CTS team to ensure that the test infrastructure exists to support this and will likely involve working with other area owners to start migrating/writing their tests in cts.
The DX team will need to be involved to ensure that we have appropriate workflows for out of tree developers and that we have appropriate documentation on fuchsia.dev.
There is no direct risk to our existing customers because the workstation is a completely separate product. The workstation runs on the session framework whereas our existing customers run on the modular framework.
It is not likely that this project will have any adverse impact on fuchsia infrastructure that is used for CI/CQ since we will be moving code and infrastructure out of fuchsia.git and using our own infrastructure. The workstation product will use open source infrastructure which is still to be determined (cirrus-ci, travis, jenkins, etc) and will run outside of fuchsia. We will need to use fuchsia infrastructure for on-device testing which could have a negative impact on our infrastructure.
There is a risk that we will introduce workflow changes which slow down the development process for in-tree developers. We already have this problem with developing other out-of-tree clients, such as Chromium and Flutter, so we can look at those workflows to identify situations that can be improved. We can help to mitigate any potential problems by working with the ux-research team to identify which workflows will break before making changes.
The biggest risk from this project is that we will not have a load-bearing product to validate the platform against in CI/CQ. This will require us to make sure that we identify the gaps that will be opened up when the Workstation product is gone and replace them with something that does not need the workstation product.