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 when to use the process i.e. the criteria for requiring an RFC.
- Socialize your proposal.
- Draft your RFC using this template. When ready to iterate, upload your CL and share it broadly to eng-council-discuss@fuchsia.dev. See also creating an RFC.
- Iterate on your proposal with appropriate stakeholders.
- As conversations on your proposal converge, and stakeholders indicate their support (+1 on the CL), or their opposition (-1 on the CL), email eng-council@fuchsia.dev to ask the Eng Council to move your proposal to Last Call.
- After a waiting period of at least 7 days, the Eng Council will accept or
reject your proposal, or ask that you iterate with stakeholders further.
- 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.
- If your RFC is rejected, a member of the Eng Council will draft a rejection rationale with you for inclusion in the RFC.
Summary of the process (deck)
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: FIDL 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-0050: FIDL Method Parameter Syntax |
| ||
RFC-0089: Core realm variations |
| ||
RFC-0090: Driver shared libraries allowlist |
| ||
RFC-0091: zx_system_get_event ZX_SYSTEM_EVENT_IMMINENT_OUT_OF_MEMORY |
| ||
RFC-0092: Sessions |
| ||
RFC-0093: Design principles of component manifests |
| ||
RFC-0094: Carnelian Virtcon |
| ||
RFC-0095: Build and assemble Workstation out-of-tree |
| ||
RFC-0096: User input architecture |
| ||
RFC-0097: FIDL Toolchain |
| ||
RFC-0098: Component Framework RFC Criteria |
| ||
RFC-0099: Introduce `zx_socket_set_disposition` |
| ||
RFC-0100: Product Metadata |
| ||
RFC-0101: Dynamic components with numbered handles |
| ||
RFC-0102: Forbid CHILD_NO_WRITE with CHILD_RESIZABLE |
| ||
RFC-0103: Software Delivery RFC Criteria |
| ||
RFC-0104: Relative Component URLs |
| ||
RFC-0105: Regular expression libraries |
| ||
RFC-0106: Component manifest includes in the Fuchsia SDK |
| ||
RFC-0107: Dynamic Offers |
| ||
RFC-0108: Component binder protocol |
| ||
RFC-0110: Reboot for termination of critical components |
| ||
RFC-0111: Initial Fuchsia hardware platform specifications |
| ||
RFC-0112: ACPI support on x86 |
| ||
RFC-0113: Efficient envelopes |
| ||
RFC-0114: Inlining small values in FIDL envelopes |
| ||
RFC-0115: Build Types |
| ||
RFC-0117: Component fuzzing framework |
| ||
RFC-0118: SWD policy at image assembly |
| ||
RFC-0119: System-absolute paths considered harmful |
| ||
RFC-0120: Standalone use of the FIDL wire format |
|
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 |
| ||
RFC-0088: Updates to RFC-0050: FIDL Bits, Enum, and Constraints Syntax |
Updates to RFC-0050: FIDL Bits, Enum, and Constraints Syntax |
| |
RFC-0116: Wire format support for sparser FIDL tables |
|
Subscribing to RFCs
You can subscribe for email notifications when new RFCs are uploaded using
Gerrit Notifications. A search expression for
docs/contribute/governance/rfcs should capture all new RFC changes.
