| {% set rfcid = "RFC-0006" %} |
| {% include "docs/contribute/governance/rfcs/_common/_rfc_header.md" %} |
| # {{ rfc.name }}: {{ rfc.title }} |
| <!-- SET the `rfcid` VAR ABOVE. DO NOT EDIT ANYTHING ELSE ABOVE THIS LINE. --> |
| |
| ## Summary |
| |
| This document proposes a refinement to the Fuchsia RFC process that takes into |
| account the challenges of the Zircon codebase. Specifically, changes to Zircon |
| that meet one (or more) of the criteria described below, must follow the RFC |
| process before being accepted. |
| |
| ## Motivation |
| |
| Currently Zircon uses an ad-hoc process to make system-wide changes, but now |
| that Fuchsia has a clear [RFC process](/docs/contribute/governance/rfcs/0001_rfc_process.md), |
| Zircon should follow it. However, given that Zircon sits at the very bottom of the |
| software stack, it is far more sensitive to certain types of changes than code that |
| sits closer to the leafs of the project (e.g., when greatly increasing the dependency |
| graph or how it balances memory usage vs performance). |
| |
| ## Design |
| |
| The vast majority of changes to Zircon do not require a RFC and a code review should |
| be sufficient. However, in addition to the considerations outlined in Fuchsia RFC process, |
| changes in the source directories: |
| |
| * /zircon |
| * /src/zircon |
| * /src/bringup |
| |
| that meet the following criteria must use RFC process: |
| |
| * *Adding or removing Zircon system interfaces.* The syscall interface, associated |
| structures and constants is the ground truth for the entire system and has broad |
| impact beyond Zircon itself and needs broad consensus before implementation. |
| |
| * *Changing resource handling behaviors.* How the system handles partitioning or |
| virtualizing resources such as memory, I/O, processor time or energy consumption |
| and what it does when they are oversubscribed or scarce. |
| |
| * *Modifying isolation guarantees.* How and what is private and isolated among |
| equal tasks and what privileged tasks can observe and modify. Changes here need to |
| be approved via this process in consultation with the security team. |
| |
| * *Significant changes of performance or memory use.* Sometimes when additional |
| security, monitoring or features are added, there is a corresponding decrease in |
| performance, or higher memory use, which need to be vetted via this process. |
| |
| * *Favoring a single platform.* Zircon strives to have an equal baseline of features |
| and services across all supported architectures and boards. Changes that leverage |
| one platform capabilities but are not feasible or practical on other supported |
| platforms need to use this process. |
| |
| * *Adding or Downgrading support for a platform.* Adding new boards or architectures, |
| or deprecating/reducing support for an existing platform needs to be vetted via |
| this process. |
| |
| * *New build configurations.* Adding new build configurations increases the development |
| and testing burden across the entire project and needs to be vetted beforehand. |
| |
| * *Significant increases on the dependency graph.* Zircon dependencies affect the |
| entire project and significant changes, for example a new dependency on a package |
| that itself has significant dependencies or that is large by itself, should use |
| the RFC process. |
| |
| Other changes that might benefit of the RFC process are ones that require manual or |
| automated large scale changes of the codebase. For example how logs are written or how |
| error paths are handled. Rather than live with islands of consistency, the aspiration |
| is to find the best patterns and uniformly apply them to the entire codebase. |
| |
| |
| ## Documentation |
| |
| This RFC along with the [Fuchsia RFC process](/docs/contribute/governance/rfcs/0001_rfc_process.md) |
| serves as documentation for the RFC process as it applies to Zircon. |
| |
| ## Drawbacks, Alternatives, and Unknowns |
| |
| The Fuchsia RFC process introduces friction that might slow down the pace of making and |
| executing decisions. The criteria in the ["when to use the process" section](/docs/contribute/governance/rfcs/0001_rfc_process.md#when-to-use-the-process) |
| attempts to mitigate this by scoping the process to consequential situations but such |
| scoping is bound to have false positives and false negatives. |
| |
| Recording decisions in the source repository has the effect of making those decisions |
| more difficult to change. That effect might be positive in some scenarios, but the effect |
| might also be negative in other scenarios. |
| |
| There are many possible alternative strategies for managing the decision-making process |
| but being aligned with the Fuchsia RFC process and its evolution as it addresses these |
| issues seems the best way forward at this time. |
| |