From Fedora Project Wiki
mNo edit summary
No edit summary
Line 33: Line 33:
The end goal of this change is to provide the modular base operating system content in a way that allows for hardware enablement and general userspace separation, enabling different update cadence and life cycles for each of the two parts.
The end goal of this change is to provide the modular base operating system content in a way that allows for hardware enablement and general userspace separation, enabling different update cadence and life cycles for each of the two parts.


Being the successor of Base Runtime, the two new modules will include all the content Base Runtime does as well as content from additional Fedora 26 Boltron modules extending it.  Additional system configuration and management services and utilities are expected to be part of the base system experience.
Being the successors of Base Runtime, the two new modules will include all the content Base Runtime does as well as content from additional Fedora 26 Boltron modules currently extending it.  Additional system configuration & management services and utilities are expected to be part of the base system experience, making all the essential content available for installation from the base level modules that are enabled by default.


== Benefit to Fedora ==


== Benefit to Fedora ==
Separating hardware enablement from general userspace makes it possible for each of the parts to have its own life cycle and update cadence, making it possible to pair one instance of the hardware enablement layer with numerous userspace modules such as "Platform F27" and "Platform F28", easily bringing support for the latest hardware to all supported Fedora releases.
 
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->


== Scope ==
== Scope ==
* Proposal owners:
* Proposal owners:
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
The Host and Platform team will prepare both modules -- define the generic module metadata, buildroots, profiles, components and API.  The team will also build the components and will deliver an installer boot image, Docker base image and virtual machines built from the Host & Platform content.  The team will also create and maintain additional modules needed to accomplish these tasks, such as a self-hosting buildroot package set module similar to the one used for building Base Runtime for Fedora 26 Boltron.  The team will assist package maintainers and release engineering with fixing packaging problems, component build and module compose issues.


* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers:
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
Package maintainers are expected to assist with fixing packaging & build issues affecting packages they maintain in a timely fashion.


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engeneering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engeneering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->

Revision as of 15:00, 25 May 2017

Host and Platform

Summary

Host and Platform is an evolution of the Base Runtime module concept introduced in Fedora 26 Boltron, splitting the minimal system further into independent modules allowing for greater flexibility when composing and maintaining the base system.

Owner

  • Name: Petr Šabata
  • Email: contyk@redhat.com
  • Release notes owner:

Current status

  • Targeted release: Fedora 27
  • Last updated: 2017-05-25
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

The end goal of this change is to provide the modular base operating system content in a way that allows for hardware enablement and general userspace separation, enabling different update cadence and life cycles for each of the two parts.

Being the successors of Base Runtime, the two new modules will include all the content Base Runtime does as well as content from additional Fedora 26 Boltron modules currently extending it. Additional system configuration & management services and utilities are expected to be part of the base system experience, making all the essential content available for installation from the base level modules that are enabled by default.

Benefit to Fedora

Separating hardware enablement from general userspace makes it possible for each of the parts to have its own life cycle and update cadence, making it possible to pair one instance of the hardware enablement layer with numerous userspace modules such as "Platform F27" and "Platform F28", easily bringing support for the latest hardware to all supported Fedora releases.

Scope

  • Proposal owners:

The Host and Platform team will prepare both modules -- define the generic module metadata, buildroots, profiles, components and API. The team will also build the components and will deliver an installer boot image, Docker base image and virtual machines built from the Host & Platform content. The team will also create and maintain additional modules needed to accomplish these tasks, such as a self-hosting buildroot package set module similar to the one used for building Base Runtime for Fedora 26 Boltron. The team will assist package maintainers and release engineering with fixing packaging problems, component build and module compose issues.

  • Other developers:

Package maintainers are expected to assist with fixing packaging & build issues affecting packages they maintain in a timely fashion.

  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

User Experience

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

N/A (not a System Wide Change)

Release Notes