The Fuchsia RFC process is intended to provide a consistent and transparent path for making project-wide, technical decisions. For example, the RFC process can be used to evolve the project roadmap and the system architecture.
The RFC process evolves over time, and can be read here in its detailed current form. It is also summarized below.
Summary of the process
- Review criteria for requiring an RFC.
- Socialize your idea.
- Draft your RFC using this template.
- Iterate your idea with appropriate stakeholders.
- After stakeholders signoff, email eng-council@fuchsia.dev to prompt the Eng Council to decide whether to accept your RFC.
- If your RFC is accepted, a member of the Eng Council will comment on your change stating that the RFC is accepted, will assign the RFC a number and mark your change Code-Review +2. Your RFC can now be landed.
Criteria for requiring an RFC
Criteria for requiring an RFC is detailed in RFC-0001.
The following kinds of changes must use the RFC process.
- Changing the project roadmap
- Adding constraints on future development
- Making project policy
- Changing the system architecture
- Delegating decision-making authority
- Escalations
In addition, changes in the source directories:
/zircon/src/zircon/src/bringup
that meet the following criteria must use the RFC process as described in RFC0006: Addendum of the RFC Process for Zircon.
- Adding or removing Zircon system interfaces.
- Changing resource handling behaviors.
- Modifying isolation guarantees.
- Significant changes of performance or memory use.
- Favoring a single platform.
- Adding or Downgrading support for a platform.
- New build configurations.
Process to submit an RFC
Once you are familiarized with the RFC guidelines and area ready to send an RFC proposal for review, see Creating a RFC.
Proposals
Active RFCs
Finalized RFCs
RFC area
Accepted
| RFC | Title | Area | Gerrit change |
|---|---|---|---|
RFC-0001: Fuchsia Request for Comments (RFC) process |
| ||
RFC-0002: Fuchsia platform versioning |
| ||
RFC-0003: Fuchsia logging guidelines |
| ||
RFC-0004: Units of bytes |
| ||
RFC-0006: Addendum of the RFC process for Zircon |
| ||
RFC-0007: Zircon removal of thread killing |
| ||
RFC-0008: Remove zx_clock_get and zx_clock_adjust |
| ||
RFC-0009: Edge triggered async_wait |
| ||
RFC-0010: zx_channel_iovec_t support for zx_channel_write and zx_channel_call |
zx_channel_iovec_t support for zx_channel_write and zx_channel_call |
| |
RFC-0011: zx_object_get_info ZX_INFO_KMEM_STATS_EXTENDED |
| ||
RFC-0012: Zircon Discardable Memory |
| ||
RFC-0013: Cloning a VMO mapping |
| ||
RFC-0014: Relax zx_fifo_create constraints |
| ||
RFC-0015: Fuchsia Compatibility Test Suite (CTS) |
| ||
RFC-0016: Boot time page sizes |
| ||
RFC-0017: The FTP Process is dead, long live the RFC Process! |
| ||
RFC-0018: FTP process: A modest proposal |
| ||
RFC-0019: Using evolution = uint64; |
| ||
RFC-0020: Interface ordinal hashing |
| ||
RFC-0021: Soft transitions for methods add and remove |
| ||
RFC-0022: Clarification: Default values for struct members |
| ||
RFC-0023: Compositional model for protocols |
| ||
RFC-0024: Mandatory source compatibility |
| ||
RFC-0025: Bit flags |
| ||
RFC-0027: You only pay for what you use |
| ||
RFC-0028: Handle rights |
| ||
RFC-0029: Increasing method ordinals |
| ||
RFC-0030: FIDL is little endian |
| ||
RFC-0033: Handling of unknown fields and strictness |
| ||
RFC-0037: Transactional message header v3 |
| ||
RFC-0040: Identifier uniqueness |
| ||
RFC-0041: Support for unifying services and devices |
| ||
RFC-0043: Documentation comment format |
| ||
RFC-0047: Tables |
| ||
RFC-0048: Explicit union ordinals |
| ||
RFC-0049: FIDL tuning process evolution |
| ||
RFC-0050: Syntax revamp |
| ||
RFC-0051: Safer structs for C++ |
| ||
RFC-0052: Type aliasing and new types |
| ||
RFC-0053: Epitaphs |
| ||
RFC-0054: Parameter attributes |
| ||
RFC-0055: Documentation comments |
| ||
RFC-0056: Empty structs |
| ||
RFC-0057: Default no handles |
| ||
RFC-0058: Introduce a deprecated attribute |
| ||
RFC-0059: Reserved bits in vector, string, and array count fields |
| ||
RFC-0060: Error handling |
| ||
RFC-0061: Extensible unions |
| ||
RFC-0066: Programmer advisory explicit defaults |
| ||
RFC-0067: Additions to Fuchsia RFC process |
| ||
RFC-0068: Page Eviction Hints |
| ||
RFC-0069: Standard I/O in ELF Runner |
| ||
RFC-0070: PCI protocol changes to support legacy interrupts |
| ||
RFC-0071: OTA backstop |
| ||
RFC-0072: Standalone Image Assembly Tool |
| ||
RFC-0074: Expose Process Start Time |
| ||
RFC-0075: Deprecate Zedboot-based paving for provisioning devices |
| ||
RFC-0076: FIDL API Summaries |
| ||
RFC-0077: zx_clock_update accuracy improvement |
| ||
RFC-0078: Kernel Sanitizer Coverage for Fuchsia Fuzzing |
| ||
RFC-0079: Detecting debuglog data loss |
| ||
RFC-0080: Detecting VMO Immutability |
|
|
|
RFC-0081: fastboot boot |
| ||
RFC-0082: Runnning unmodified Linux programs on Fuchsia |
| ||
RFC-0083: FIDL versioning |
| ||
RFC-0084: Add more metrics to zx_info_task_runtime_t |
| ||
RFC-0085: Reducing the zx_status_t space |
| ||
RFC-0086: Updates to RFC-0050: FIDL Attributes Syntax |
| ||
RFC-0087: Updates to RFC-050: FIDL Method Parameter Syntax |
| ||
RFC-0089: Core realm variations |
|
Rejected
| RFC | Title | Area | Gerrit change |
|---|---|---|---|
RFC-0005: Blobfs snapshots |
| ||
RFC-0026: Envelopes everywhere |
| ||
RFC-0031: Typed Epitaphs |
| ||
RFC-0032: Efficient envelopes |
| ||
RFC-0034: Null terminate strings |
| ||
RFC-0035: Automatic flow tracing |
| ||
RFC-0036: Update to struct declarations |
| ||
RFC-0038: Seperating layout from constraints |
| ||
RFC-0039: Types come second |
| ||
RFC-0042: Non nullable types |
| ||
RFC-0044: Extensible method arguments |
| ||
RFC-0045: Zero-size empty structs |
| ||
RFC-0062: Method impossible |
| ||
RFC-0063: OrdinalRange |
| ||
RFC-0064: Box <Knox> |
| ||
RFC-0065: No optional strings or vectors |
|