Internal only link: go/fb-owners.
As general background, OWNERS (especially <TEAM>_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.
- Create your
OWNERSfile change:
- Please follow structure in "Review Structure" section below.
- Please include a bug component. See "Bug Component" section below.
- Follow these steps to get it reviewed in Gerrit quickly:
- please find the people that normally work on this code. For instance, check git history and/or review history. These people who own the code but are not yet reflected in the owners system are called the "de facto OWNERS".
- add a screenshot of recent git maintainers and/or reviewers to the Gerrit review in a comment, showing that the "de facto OWNERS" really are represented. If you don't do this, whoever is approving the change has to do this research themselves. Internal only: go/sniplt will make this fast!
- add the "de facto OWNERS" as a reviewer to Gerrit initially to approve themselves and any other reviewers that you are adding.
- once they approve, add one (and only one) LAST_RESORT_OWNERS as reviewers from frameworks/base/OWNERS. These people get many many reviews, so doing research to make sure OWNERS are properly reflected make it very easy for them to approve. These are the reviewers that Gerrit will suggest on "unowned" files.
- Relax & celebrate! Good job!
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, we recommend <TEAM>_OWNERS files at the root of
frameworks/base.
Area maintainers are strongly encouraged to list people in a single
authoritative OWNERS file in exactly one location, preferably at the
frameworks/base root directory. 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.
For some common teams, these authorative places can be used:
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 thancore/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 mainservices/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/
Always include an up-to-date bug component in the top-level <TEAM>_OWNERS files:
# Bug component: XXX
The exact syntax of OWNERS files can be difficult to get correct, so here are
some common examples:
# Complete include of top-level owners from this repo
include /ZYGOTE_OWNERS
# Partial include of top-level owners from this repo
per-file ZygoteFile.java = file:/ZYGOTE_OWNERS
# Complete include of subdirectory owners from this repo
include /services/core/java/com/android/server/net/OWNERS
# Partial include of subdirectory owners from this repo
per-file NetworkFile.java = file:/services/core/java/com/android/server/net/OWNERS
# Complete include of top-level owners from another repo
include platform/libcore:/OWNERS
# Partial include of top-level owners from another repo
per-file LibcoreFile.java = file:platform/libcore:/OWNERS
# Complete include of subdirectory owners from another repo
include platform/frameworks/av:/camera/OWNERS
# Partial include of subdirectory owners from another repo
per-file CameraFile.java = file:platform/frameworks/av:/camera/OWNERS