Google is committed to advancing racial equity for Black communities. See how.

RFC-0103: Software Delivery RFC Criteria

RFC-0103: Software Delivery RFC Criteria
StatusAccepted
Areas
  • Software Delivery
  • Governance
Description

An addendum to the RFC process for changes which affect the Software Delivery codebase or policies.

Gerrit change
Authors
Reviewers
Date submitted (year-month-day)2021-05-19
Date reviewed (year-month-day)2021-06-10

Summary

Criteria for changes which require RFCs in the Software Delivery area.

Motivation

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. 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.

Design

Changes which require an RFC

  • Changes to the system update flow which add restrictions or gates, or new error conditions to the OTA process. For example, adding additional checks before completing an OTA, or making OTA downgrade checking more strict.
  • Changes to how we use package repositories, or the structure of package repositories we expect. We expect that both internal and external developers may create or host their own TUF servers, and we should provide appropriate notice of changes to the expected format.
  • Changes to the Fuchsia package format. Anything that modifies the schema for Fuchsia packages or the Fuchsia Archive format.
  • Adding or removing requirements for a product or build type to support OTA system updates. For example, requiring vbmeta to OTA successfully, or removing a requirement for vbmeta.
  • Modifications to enforcement of security policies. For example, changing executability restriction strategies.
  • Changes which may make old systems fail to update to newer system versions, or require stepping-stone builds.
  • Changes which will substantially increase resource usage. Whether memory, disk, CPU, network, etc.
  • Modifications to privacy policies or their enforcement. We don't have much ability to transact PII in the codebase today, but if we someday want to, that should go through an RFC.

Examples: past changes which would now require an RFC

  • OTA backstops; changes to the OTA process.
  • Post-OTA health checks; changes to the OTA process.
  • Changes to the package format, like a meta/contents overhaul.
  • Migrating to channel in vbmeta; changes to OTA process and requirements for OTAs.

Examples: past changes which would still not require an RFC

  • CFv2 migrations; they are covered by other artifacts.
  • Blob download resumption; optional feature unobservable outside of pkg-resolver, risks were mitigated in code review process.
  • Changes to metrics or inspect emitted by the SWD stack.
  • Additions of channels for products.
  • Reliability improvements, like making fx ota work well for kernel developers. PSAs are sufficient here if the risk of regression is small.
  • Deprecating 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.

Implementation

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.

Performance

No impact, process-only change.

Ergonomics

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.

Backwards Compatibility

No impact.

Security Considerations

Changes to the SWD area which modify security strategy will require an RFC, per these criteria.

Privacy considerations

Changes to the SWD area which modify privacy considerations will require an RFC, per these criteria.

Testing

No impact.

Documentation

We'll update the current RFC process documentation if this RFC is accepted.

Drawbacks, alternatives, and unknowns

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.

Prior art and references