From Fedora Project Wiki
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{draft}}
== Objective: Fedora Modularization, Prototype Phase ==
== Objective: Fedora Modularization, Prototype Phase ==


Line 15: Line 13:


<!-- SVG source at https://pagure.io/fm-overview/tree/master -->
<!-- SVG source at https://pagure.io/fm-overview/tree/master -->
[[File:Modularization-phase3-logicmodel-v3-20160309.png|900px]]
[[File:Modularization-phase3-logicmodel-v3-20160310.png|960px]]
 
'''
''Todo: expand Activities, fill out Resources'''''


=== More Details ===
=== More Details ===


See [[Modularization]] for background and oh so many details.
See [[Modularization]] for background and oh so many details.
When we get to doing actual work, actual activities won't be tracked in the graphic above; that will be done in [http://taiga.fedorainfracloud.org/project/langdon-modularity/ Taiga].


=== Deliverables ===
=== Deliverables ===
Line 34: Line 31:
* minimized dependencies (ongoing work)
* minimized dependencies (ongoing work)


== Modules Working Group (to replace Base and Env & Stacks) ==
== Modularity Working Group (to replace Base and Env & Stacks) ==
 
{{side box|
'''Alternative proposal — Re-Charter Existing Groups'''
 
Rather than replacing the existing working groups, we could redefine and remake them.
 
The primary work for this will be done by re-chartered Base Working Group and Environments and Stacks Working Group. This project is roughly in line with what they were created to do in the first place, but without a specific focus, they kind of drifted and eventually have trailed off in activity. This is a perfect time to restart them with new purpose.
 
The effort will also require help and resources from across Fedora, including Fedora Infrastructure, Release Engineering, QA, Security Team, and more. Members of those groups should be included on the new Working Groups.
 
=== Base Working Group (Alternative Proposal) ===
 
The purpose of the Base Working group is to '''define and maintain the Fedora Base Module, including producing and releasing it in artifact form''' — as a Docker base image, as an installable minimal system, and possibly in other ways in the future. This will not be a Fedora Edition, but rather be the thing people constructing custom versions of Fedora can start from — including both advanced end-users and Fedora Spins and Editions. (See interesting
[http://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/message/K45OPPE5GN3V4MME5FTN7NM6PNESWA5L/ background discussion on the Fedora Server mailing list]].)
 


=== Environments and Stacks Working Group (Alternative Proposal) ===
Effort on this Objective will be undertaken by a new "'''Modularity Working Group'''". This will replace the existing Base Working Group and Environments and Stacks Working Group.


The Environments and Stacks Working Group '''explores new technologies for getting software to users through Fedora and creates and maintains guidelines for doing so'''. This includes creating tooling for producing and maintaining Fedora modules, integrating non-RPM content in a maintainable and secure way, and investigating emerging approaches for software distribution.
The goal of the Modularity Working Group is to '''define and maintain the Fedora Base Module and guidelines and tools for other modules'''.
 
 
}}
 
 
Effort on this Objective will be undertaken by a new "'''Modules Working Group'''". This will replace the existing Base Working Group and Environments and Stacks Working Group.
 
The goal of the Modules Working Group is to '''define and maintain the Fedora Base Module and guidelines and tools for other modules'''.


This includes '''releasing the Fedora Base Module in artifact form on a regular schedule''' — as a Docker base image, as an installable minimal system, and possibly in other ways in the future. This will not be a Fedora Edition, but rather be the thing people constructing custom versions of Fedora can start from — including both advanced end-users and Fedora Spins and Editions. (See interesting  
This includes '''releasing the Fedora Base Module in artifact form on a regular schedule''' — as a Docker base image, as an installable minimal system, and possibly in other ways in the future. This will not be a Fedora Edition, but rather be the thing people constructing custom versions of Fedora can start from — including both advanced end-users and Fedora Spins and Editions. (See interesting  
[http://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/message/K45OPPE5GN3V4MME5FTN7NM6PNESWA5L/ background discussion on the Fedora Server mailing list]].)
[http://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/message/K45OPPE5GN3V4MME5FTN7NM6PNESWA5L/ background discussion on the Fedora Server mailing list].)


So that modules are useful in the greatest number of situations, are fast to create and to deploy, and have the smallest possible security footprint, the Modules Working Group will '''reduce package dependency trees''', particularly in the Fedora Base Module.
So that modules are useful in the greatest number of situations, are fast to create and to deploy, and have the smallest possible security footprint, the Modularity Working Group will '''reduce package dependency trees''', particularly in the Fedora Base Module.


The Working Group will also '''produce tooling for module production and maintenance, and guidelines for modules''', as the FPC does for RPMs.
The Working Group will also '''produce tooling for module production and maintenance, and guidelines for modules''', as the FPC does for RPMs.
Line 73: Line 47:
The effort will also require help and resources from across Fedora, including Fedora Infrastructure, Release Engineering, QA, Security Team, and more. Representatives of those groups should be included on the new Working Group. Also, proven packagers working as part of this effort will institute weak dependencies in a systematic manner, in cooperation with package maintainers.
The effort will also require help and resources from across Fedora, including Fedora Infrastructure, Release Engineering, QA, Security Team, and more. Representatives of those groups should be included on the new Working Group. Also, proven packagers working as part of this effort will institute weak dependencies in a systematic manner, in cooperation with package maintainers.


== Notes (draft) ==


{{admon/note|So basically...|The Modularity WG includes what are now Base WG functions, plus some of what was in the area of Environments and Stacks, plus the new thing of actually making a released artifact on a regular cadence (which gives a concrete ongoing focus, in addition to the work outlined here). So, Base WG will be entirely folded in. We will "mothball" Environments and Stacks as it exists now; it might be revised in the future with a new charter when we get to further Fedora.next ideas (like including non-RPM packages directly) — but we're not ready for that now.}}


=== For the Fedora Base Module ===
== Objective Lead ==


* Target 50MB on disk
* Create pagure repo for experimentation with specs and rpms should
* COPR build repo
* Specific changes proposed to and ratified by FESCo (FPC?)
* Proven packagers to make changes to all affected packages in Rawhide
* Monitor changes to packages to ensure no “growth”


=== For the Tooling and Guidelines and Beyond ===
[[user:langdon|Langdon White]]


* Should include members of Fedora Rel-Eng and Fedora Security Team
== Timeframe ==
* Phase 1 (Roughly until F24 release)
** Figures out what a “module” actually is in practice
** Required stakeholders
*** Fedora Release Engineering
*** Fedora Security Team
*** Base WG
** Creates whatever tools needed to produce and use modules
*** using existing tooling and systems where possible
*** rely on Fedora Release Engineering for changes to infrastructure where required
*** Fedora Infrastructure may also need changes
** Defines & creates demo modules other than base
* Phase 2 (F25 timeframe)
** Defines guidelines for module definition
*** Approved and ratified by FeSCO
** Changes to packaging guidelines as needed
** Approved and ratified by FPC
** Module definition storage and hosting
*** relies on implementation by Fedora Release Engineering
** CI infrastructure for modules, relies on work by
*** Fedora Infrastructure
*** Fedora QA
*** Fedora Release Engineering
* Phase 3 (ongoing)
** After all this is done, become some sort of Fedora Module Guidelines Committee in parallel with (or as part of) FPC
** Actually, parallel to Phase 1 & 2


== Objective Lead ==
The prototype should be available around the time of the Fedora 25 release. We should be able to show it off at FOSDEM and DevConf.cz in January/February 2017.


In order for that to happen, the initial technical definition of what modules will ''be'', how they will be implemented for the prototype, and initial tooling, needs to be done by approximately the Fedora 24 release, in June 2016.


[[user:langdon|Langdon White]]
By Flock in August (also of this year), we should be able to start planning and discussing the ''next'' phase, even if the prototype and tooling aren't complete.


== Timeframe ==
The new Modules Working Group will continue beyond this objective, as described above.
 
This phase should be complete by the Fedora 25 release. The re-chartered Base and Env & Stacks Working Groups will be ongoing.


== History ==
== History ==


Follows from [[Objectives/Fedora Modularization, Requirements Phase]]
Follows from [[Objectives/Fedora Modularization, Requirements Phase]]
Initial council approval: [https://meetbot.fedoraproject.org/teams/council/council.2016-03-14-18.00.html March 14th, 2016]

Revision as of 16:23, 15 March 2016

Objective: Fedora Modularization, Prototype Phase

Also known as: the Let's Get Real Phase, or, Less Talk, More... Modules

Goal

The goal of this phase is to deliver a functional implementation of modular Fedora. We will be able to create, demonstrate, and deploy Fedora-based solutions made from independent modules which can move at their own paces yet still be trusted to work together and to be kept secure.

Logic Model

The basic idea: planning flows from right to left, and actual effort back from left to right. To the left of the double line is stuff we can actually do; to the right of that line, stuff we expect to be true as a result. See this blog post for more on this planning tool.


Modularization-phase3-logicmodel-v3-20160310.png

More Details

See Modularization for background and oh so many details.

When we get to doing actual work, actual activities won't be tracked in the graphic above; that will be done in Taiga.

Deliverables

The primary deliverable will be a functioning prototype of "modular Fedora", in the Fedora 25 timeframe. This need not be perfect, but it needs to be functional enough that people can use it, understand it, hammer on it, and improve it.

As part of making this prototype, other deliverables include:

  • Working modules of various types, including a minimal base module
  • a automated testing and continuous delivery system for modules
  • a better way of dealing with different versions of the same software
  • minimized dependencies (ongoing work)

Modularity Working Group (to replace Base and Env & Stacks)

Effort on this Objective will be undertaken by a new "Modularity Working Group". This will replace the existing Base Working Group and Environments and Stacks Working Group.

The goal of the Modularity Working Group is to define and maintain the Fedora Base Module and guidelines and tools for other modules.

This includes releasing the Fedora Base Module in artifact form on a regular schedule — as a Docker base image, as an installable minimal system, and possibly in other ways in the future. This will not be a Fedora Edition, but rather be the thing people constructing custom versions of Fedora can start from — including both advanced end-users and Fedora Spins and Editions. (See interesting background discussion on the Fedora Server mailing list.)

So that modules are useful in the greatest number of situations, are fast to create and to deploy, and have the smallest possible security footprint, the Modularity Working Group will reduce package dependency trees, particularly in the Fedora Base Module.

The Working Group will also produce tooling for module production and maintenance, and guidelines for modules, as the FPC does for RPMs.


The effort will also require help and resources from across Fedora, including Fedora Infrastructure, Release Engineering, QA, Security Team, and more. Representatives of those groups should be included on the new Working Group. Also, proven packagers working as part of this effort will institute weak dependencies in a systematic manner, in cooperation with package maintainers.


Note.png
So basically...
The Modularity WG includes what are now Base WG functions, plus some of what was in the area of Environments and Stacks, plus the new thing of actually making a released artifact on a regular cadence (which gives a concrete ongoing focus, in addition to the work outlined here). So, Base WG will be entirely folded in. We will "mothball" Environments and Stacks as it exists now; it might be revised in the future with a new charter when we get to further Fedora.next ideas (like including non-RPM packages directly) — but we're not ready for that now.

Objective Lead

Langdon White

Timeframe

The prototype should be available around the time of the Fedora 25 release. We should be able to show it off at FOSDEM and DevConf.cz in January/February 2017.

In order for that to happen, the initial technical definition of what modules will be, how they will be implemented for the prototype, and initial tooling, needs to be done by approximately the Fedora 24 release, in June 2016.

By Flock in August (also of this year), we should be able to start planning and discussing the next phase, even if the prototype and tooling aren't complete.

The new Modules Working Group will continue beyond this objective, as described above.

History

Follows from Objectives/Fedora Modularization, Requirements Phase

Initial council approval: March 14th, 2016