1**Fill in all sections demarcated in <> brackets and then delete this. Send to 2g/chromeos-<program>, g/chromeos-peng-sies, platform project leads, and 3g/cros-boxster-announce.** 4 5**Configuration for <program> will now be managed on a per-project basis 6with the goal of enabling autonomous and flexible partner contributions and 7clearer API boundaries. Once we receive acknowledgement from project owners, the 8migration CL will be submitted within 2 to 3 business days** 9 10Starlark -- a Python-like configuration-management language -- will be used to 11generate Protocol Buffer configuration payloads in <repos> and model.yaml will 12be deleted from <private overlay>. A few resources 13to get started: 14 15* [Starlark language guide](https://docs.bazel.build/versions/master/skylark/language.html) 16* [chromiumos/config README](https://chromium.googlesource.com/chromiumos/config/+/HEAD/README.md): 17 Steps for partners and Googlers to check out their repos and contribute 18 changes. 19* [fake test data project](https://chromium.googlesource.com/chromiumos/config/+/HEAD/test/project/fake/fake): 20 Working example of the new config ecosystem. 21 22Changes will be made in the following repos: 23 24* <new config repos>: Contains Starlark files, generated protobuf payloads, 25 and backwards-compatible JSON payloads. 26* <private overlay>: <chromeos-config-bsp ebuild> sets `CROS_WORKON_PROJECT` 27 to <new config repos>. model.yaml is deleted. 28 29We understand that getting used to the new configuration management ecosystem 30may take some time, and are committed to providing the best experience possible 31for partners and Googlers. Please contact the project TAM/SIE for issues and 32feedback, which will be relayed in timely fashion. 33 34## Frequently Asked Questions 35 361. **Why are we doing this migration?** 37 38Configuration data for ChromeOS hardware, firmware, and software has been spread 39across multiple data silos and formats. This has made the effects of configuration 40changes confusing and inhibited analytics that could drive project planning and 41infrastructure. This migration will provide a coherent and clear API ecosystem. 42 43Benefits include: 44 45* Clearer API boundaries to manage builds and hardware. 46* Enable autonomous partner config contributions, enforced via CQ coverage. 47* Allow partners to develop proprietary features without leaking IP. 48* Final generated config payloads are checked in allowing for clear behavior 49 and diffing. 50* Improved analytics on hardware and software characteristics. 51 522. **Will I need to change my ChromeOS platform code?** 53 54No. For the time being, the protobuf payloads will be translated backwards into 55JSON payloads conforming to 56[cros\_config\_schema.yaml](https://chromium.git.corp.google.com/chromiumos/platform2/+/HEAD/chromeos-config/cros_config_host/cros_config_schema.yaml). 57From the platform point-of-view, the configuration will not change. 58 593. **Will this break my builds?** 60 61No. During the migration, we will ensure that configuration generated by the new 62repos is the same as the configuration generated by model.yaml. Standard CQ 63coverage will apply to the migration CLs and stakeholders will be added as 64reviewers. Migration will be done in a single submission that can be reverted. 65 664. **How will I cherry pick changes to branches?** 67 68If your project has not yet created branches, you will only need to cherry pick 69changes to the generated payloads in the new config repos. If your project has 70created branches, you will need to cherry pick the ebuild change to read the new 71config repos as well. The Boxster team will be available to assist in the cherry 72pick process. 73