From 061c2ec3b61fb2d62be2c46dee9696e5710dc55f Mon Sep 17 00:00:00 2001 From: Jeff Sharkey Date: Sat, 5 Dec 2020 22:30:34 -0700 Subject: Improve OWNERS coverage across frameworks/base/. As general background, OWNERS files expedite code reviews by helping code authors quickly find relevant reviewers, and they also ensure that stakeholders are involved in code changes in their areas. Some teams under frameworks/base/ have been using OWNERS files successfully for many years, and we're ready to expand them to cover more areas. Here's the historical coverage statistics for the last two years of changes before these new OWNERS changes land: -- 56% of changes are fully covered by OWNERS -- 17% of changes are partially covered by OWNERS -- 25% of changes have no OWNERS coverage Working closely with team leads, we've now identified clear OWNERS on a per-package basis, and we're using "include" directives whenever possible to to simplify future maintenance. With this extensive effort, we've now improved our coverage as follows: -- 98% of changes are fully covered by OWNERS -- 1% of changes are partially covered by OWNERS -- 1% of changes have no OWNERS coverage This specific change begins defining top-level OWNERS lists, including a general catch-all for string translations. Bug: 174932174 Test: manual Exempt-From-Owner-Approval: refactoring with team leads buy-in Change-Id: Ie7ac3302d40a717fa048115cca2ea4359de64959 --- OWNERS.md | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 OWNERS.md (limited to 'OWNERS.md') diff --git a/OWNERS.md b/OWNERS.md new file mode 100644 index 000000000000..6428c59fd793 --- /dev/null +++ b/OWNERS.md @@ -0,0 +1,34 @@ +As general background, `OWNERS` files expedite code reviews by helping code +authors quickly find relevant reviewers, and they also ensure that stakeholders +are involved in code changes in their areas. + +The structure of `frameworks/base/` is unique among Android repositories, and +it's evolved into a complex interleaved structure over the years. Because of +this structure, the best place to authoritatively define `OWNERS` can vary +wildly, but here are some common patterns: + +* `core/java/` contains source that is included in the base classpath, and as +such it's where most APIs are defined: + * `core/java/android/app/` + * `core/java/android/content/` +* `services/core/` contains most system services, and these directories +typically have more granularity than `core/java/`, since they can be refactored +without API changes: + * `services/core/java/com/android/server/net/` + * `services/core/java/com/android/server/wm/` +* `services/` contains several system services that have been isolated from the +main `services/core/` project: + * `services/appwidget/` + * `services/midi/` +* `apex/` contains Mainline modules: + * `apex/jobscheduler/` + * `apex/permission/` +* Finally, some teams may have dedicated top-level directories: + * `media/` + * `wifi/` + +Area maintainers are strongly encouraged to list people in a single +authoritative `OWNERS` file in **exactly one** location. Then, other paths +should reference that single authoritative `OWNERS` file using an include +directive. This approach ensures that updates are applied consistently across +the tree, reducing maintenance burden. -- cgit v1.2.3