{% set rfcid = “RFC-0103” %} {% include “docs/contribute/governance/rfcs/_common/_rfc_header.md” %}
Criteria for changes which require RFCs in the Software Delivery area.
The Software Delivery (SWD) system has wide scope over system behaviors, including over the air (OTA) system updates, development and testing flows, device security, and eventually package updates without a system update. Changes to the SWD stack can modify behavior of the system in subtle ways and incur cost to the Fuchsia program. To best adhere to the Fuchsia-wide RFC process, we seek to disambiguate the changes which have ‘broad impact’ in the SWD area by putting forth a set of clear criteria. These criteria are an attempt to achieve a balance between execution velocity and proper stakeholder communication and approval processes.
meta/contents
overhaul.fx ota
work well for kernel developers. PSAs are sufficient here if the risk of regression is small.amberctl
and moving developers over to pkgctl
. This should be handled by the LSC process, as the workflows and goals of the tools are almost entirely the same.Ongoing work that already has design approval through other processes and is in implementation will not be required to submit retroactive RFCs in order to go ahead. However, we should submit retroactive RFCs for portions of the Software Delivery stack which are sufficiently direction-setting and are under-documented in other places. We'll evaluate ongoing or nearly-landed work on a project-by-project basis to determine if we should write a retroactive RFC for it.
Work which is not yet past the design stage will be required to adhere to these guidelines.
These guidelines will be effective as of their RFC publication date, and we‘ll add them to the current process page in the RFC documentation. If we update these guidelines, we’ll do so as an addendum to this RFC in a subsequent CL.
If a contributor wishes to work with the SWD team on an RFC, they should feel free to reach out to pkg-dev@fuchsia.dev and we'll assign them a designated contact.
No impact, process-only change.
We'll revisit these criteria if we find that changes are going through which would have been better communicated by RFCs, or if we find in some other way we need to modify these criteria. We need to strike a balance of execution velocity and communication, regardless of the criteria.
No impact.
Changes to the SWD area which modify security strategy will require an RFC, per these criteria.
Changes to the SWD area which modify privacy considerations will require an RFC, per these criteria.
No impact.
We'll update the current RFC process documentation if this RFC is accepted.
There are many alternative criteria we could use. We should amend this list if we find that too many “small” changes require RFCs based on this criteria, or we find that not enough “large” changes are going through the RFC process.