Objectives/Lifecycle

The Fedora Project has been producing an operating system for general use for 15 years. For at least the last decade, the general methodology for doing so has barely changed. That methodology makes it hard to accommodate projects with different cadence. It also unnecessarily restricts the group of people able to particpate. This problem constrains Fedora's rate of innovation, and creates unwanted friction with well-aligned, interesting projects such as Fedora CoreOS.

Definitions

artifact

A unit of software intended to be used on its own or in combination with other software for testing or consumption.

An example is an RPM package, a module, or a Flatpak.

deliverable

A collection of artifacts intended for public distribution and/or general use.

An example is a container, or a qcow2 or ISO image.

platform

A deliverable that provides a host operating system with basic functionality, including the ability to add applications and/or artifacts.

application

Any artifact or group of artifacts not required to run a host operating system.

Current issues

The entire set of Fedora deliverables, with few exceptions, are "due" at once, on a single lifecycle, and all maintainer and developer work must fit into that schedule. This approach in one sense can be seen as making all packages "equal." Whether a package is needed for a well-functioning platform or not, it must be constrained to the same schedule.

In the meantime, modern IT and OS trends are toward faster iteration, especially when it comes to applications and stacks. With a more constrained OS surface, applications can be "freed" to innovate more quickly. And on the other hand, needn't be made ready at an arbitrary schedule meant to promote either platform innovation or stability.

To restate in very simple terms: By separating and minimizing what Fedora puts out as a platform, we can put more cycles into development to put capabilities in the hands of the community.

Goals

This Objective aims to decouple the platform and application lifecycles to minimize this problem. The visionary goal is in the future:

• Fedora will be able to release one or more constrained platform releases, on an agreed upon schedule
• Other deliverable, application, and artifact maintainers can make releases based on upstream or other target schedules

Deliverables and scope

Along the way this goal implies that other improvements are either required or helpful:

The project migrates toward modules and stream branching (probably not necessary for all packages).

This facility uses streams like 1.2 or 2.0 instead of f30, f31, etc. for managing branches of applications.

Also implies that we need a way to mark a module stream as to be used in the buildroot for non-modular artifacts.

The project provides services for stream expansion that build and test streams of software against any desired platform targets (such as a Fedora or EL release).

This reduces maintainer workload since they can update software based on upstream releases in a single branch to generate multiple artifacts or deliverables.

Release process and tools are adapted in several phases.

Minimizing the platform target size

Relying more heavily (and likely more universally) on CI (continuous integration) to perform gating operations

Increasing the scalability of building and composing artifacts and deliverables

Adapting tools into services that can be activated by a larger population of community members

It is also anticipated that Modularity will provide a flexible solution for a substantial number of applications and other deliverables. At some point, it will be a good idea to incorporate module build guidelines into the mainline of our policies as well.

More details
There is a more detailed writeup of specific problems and proposed solutions on this wiki page.

Key results

• Definition of a platform release, where that release includes:
  • Reduction in the number of deliverables required at a platform release
  • Reduction in the amount of content required in a platform release
  • Note: This does not require an exclusive definition of the platform. As long as we start with an agreed-upon subset, the content can be tuned over time. We aren't going to lock this up by deciding "in or out?" on a per-package basis at the outset.
• Accurate tooling allowing modularization anywhere needed outside the platform
• A set of key applications and other deliverables available for a range of platforms (Fedora and CentOS releases)
• Shorter platform compose time (savings TBD)

Plans and work areas

Discovery phase (through Oct/Nov 2018):

• Determine best place(s) to conduct work, work may be spread across multiple platforms as needed to experiment:
  • Fedora OpenShift instance
  • Public cloud
  • Centos.org
  • Others?
• Investigation of release pipeline to determine, or pull in input from participants:
  • any quick wins for automation or optimization
  • profiling to determine outlying time sinks
  • readjudicate areas of concern -- are there any assumptions in the way that we should re-examine?
• Develop prioritized schedule of upcoming changes
  • Publish for community awareness

Work phase (starting Dec 2018):

• Modularity fixes as needed
• RPM scriptlet removal
• Increase automated testing
  • gather failure cases from QA, rel-eng, others
• CI/CD tie-in
  • one of the primary targets is fast iteration of a small-platform OS that can be tested to gate artifacts
• Revamp additional compose tools
• Other, TBD

Objective lead

• Paul W. Frields -- will represent product owner -- define vision, manage priorities, provide oversight and communications

The product owner will work closely with the FPL, a technical team of additional, Fedora-friendly contributors to be led by Petr Šabata, the CI objective lead, the Release engineering team, the Infrastructure team, and contributors to Factory 2.0 to coordinate activities.