[council] #26: Objective Proposal: Fedora Modularization (Requirements Phase)

[fedora-badges]

#26: Objective Proposal: Fedora Modularization (Requirements Phase)
------------------------+-------------------
 Reporter:  langdon     |     Owner:
   Status:  new         |  Priority:  normal
Component:  Objectives  |  Keywords:
------------------------+-------------------
 = 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?)

-- 
Ticket URL: <https://fedorahosted.org/council/ticket/26>
council <https://fedorahosted.org/council>
Fedora Council Public Tickets