#26 Objective Proposal: Fedora Modularization (Requirements Phase)
Closed: Fixed None Opened 8 years ago by langdon.

This a approved; see on wiki → https://fedoraproject.org/wiki/Objectives/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.
  2. 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
  3. 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?)

Full disclosure... I helped draft this. So this comment is a little bit "oh now you suggest this", but, anyway:

I suggest retitling "Impact" to "Output artifact", and adding under "Impact": "We'll have a clear picture of the technical requirements and problems to be solved, allowing us to move to Phase II, identification of actual solutions."

Also, while I totally agree with the phased approach here and not getting too far ahead of ourselves, it might be good to phrase this objective as an 18 month target including all three phases as part of the objective up front, even if we don't have the details of the later parts worked out.

One thing - draft mentions only WGs/Editions - it should be extended to cover SIGs/spins too as composition of base system is going to affect almost every single deliverable we have. And one outcome of modularization could be the end of spins as we know them (in the way Formulas were proposed some time ago). For examples desktops would be just modules on top of Workstation base, sets of applications that creates spins would be again only modules on top of base+workstation+desktop with specific setting applied on the fly.

To go back one step here, the key high-level thing ''I'm'' hoping to address is the "too-fast / too-slow" problem (http://www.reddit.com/r/linux/comments/37l2mf/i_am_matthew_miller_fedora_project_leader_ask_me/crnlcst).

Approved in council meeting today with no objections. Also, Langdon approved as objective lead.

http://meetbot.fedoraproject.org/fedora-meeting/2015-06-01/council.2015-06-01-17.00.html

Login to comment on this ticket.

Metadata