Initiatives/Fedora Modularization, Requirements Phase

Fedora Modularization: Fedora.next: What is Next (Requirements Phase)

Background

We have had much discussion of the "rings proposal" and "fedora.next." However, it has not been completely clear what to "do next" now that the proposal has been accepted. While, the largest change has been made (introduction of "editions"), it is time to focus on the next steps. I (and others) thought it would be helpful to have an "Objective" to coalesce the work.

Objective: Fedora Modularization: Fedora.next: What is Next (Requirements Phase)

Overview

For this Objective, we want to specifically focus on the “technical” aspects of the rings proposal(s). By “technical” we mean "how we want to move forward regarding the composition of the OS (in all Fedora Editions)". However, we don’t expect the participants in the discussion to be limited to technical folks.

While much discussion has taken place regarding methods for distribution, what has become most clear is that there are a number of constituencies within Fedora which have competing, and perhaps, conflicting requirements for the long term plan.

Expected Impact

• A set of requirements, perhaps conflicting, to move forward with

Timeframe

We need to move quickly on this work. Proposing that the requirements list(s) be complete by Flock 2015.

Approach

Fedora.next Modularization will be tackled in three phases (requirements gathering, solution identification & agreement, and, finally, implementation), this Objective covers the first of those phases. For the "requirements gathering" phase, we expect to:

1. Ask the WGs to identify segments of their user population which may benefit from a modularized approach to OS composition. Please use the list below to get started. 1. Ask the WGs to reach out to their population segments to get feedback. Perhaps sending an email to the appropriate mailing list and holding 2-3 "town hall" meetings (by segment) to gather feedback 1. Provide both the raw feedback and prioritized set of requirements, by user segment, to the Objective Team

Detailed Approach

We have identified several different types of Fedora user. Some of these user types might benefit strongly from this approach; for others, perhaps less. These different groups are Fedora users who:

• Wish to primarily run Fedora approved applications for the full lifecycle of a given release (or longer)
• Wish to primarily run 3rd party applications for the full lifecycle of a given release (or longer)
• Develop applications based on frameworks provided by Fedora but will ultimately be deployed to a server (i.e. web apps)
• Develop applications based on frameworks provided by Fedora which will be deployed on desktops (e.g. gnome-boxes)
• Develop components of Fedora itself or the frameworks Fedora provides (e.g. kernel, apache, python)

Side note: here, “Fedora approved” means a binary in an official Fedora repository of some kind (might be main rpms, playground, or some other method of distribution).

We would like to ask the WGs to identify which of the above applies to their existing user population. And, of course, propose any other additional categories that may have been missed.

Next, we would like the WGs to gather feedback from users, by user category. Below find some ideas for questions or topics; please share with us (and the other WGs) any other questions/topics you come up with.

• Nature of updates: disconnected updates, connected updates, live updates, user initiated, automatic
• Support for multiple versions of "components" (either dependencies or user tools)
• "Quality" of available components. Multiple aspects here: Are beta versions of tools available? Improperly packaged components? Does "method of delivery" (e.g. containers vs rpm) change the opinions? (For example, if a beta of a tool was delivered in a container that couldn't "hurt" the base OS, would that be more acceptable than a tradtional RPM?)
• Flexibility: Is it OK to have components that are not installable together? Or "sets of components" that work together and come as a unit? (Made up example: "php-support" can be provided by the "php-nginx" or the "php-apache" but you can't have both at once)
• Can/should different sub-components have different "lifecycles" vs the OS? (For example, can F23 ship with Gnome 3-LTS but then have Gnome-Fast shipping within the F23 lifecycle?)

Objective Lead:

Langdon White

History:

Initial council approval: June 1st, 2015