From Fedora Project Wiki
< Changes
(Small correction.) |
(Finish the change.) |
||
| Line 75: | Line 75: | ||
<!-- 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?--> | <!-- 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?--> | ||
** Split Anaconda to modules with DBus API. | ** Split Anaconda to modules with DBus API. | ||
** Old UI must be | ** Old UI must be modified to use new DBus API. | ||
* Other developers: <!-- N/A (not a System Wide Change) --> <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Other developers: <!-- N/A (not a System Wide Change) --> <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
| Line 81: | Line 81: | ||
** Thanks to the nature of how addons work right now, we need a cooperation from the Anaconda addon developers. | ** Thanks to the nature of how addons work right now, we need a cooperation from the Anaconda addon developers. | ||
* Release engineering: [https://pagure.io/releng/ | * Release engineering: [https://pagure.io/releng/issue/7240 #7240] <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES --> | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | ||
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | ||
| Line 155: | Line 155: | ||
TODO | TODO | ||
[[Category: | [[Category:ChangeReadyForWrangler]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
Revision as of 12:11, 5 January 2018
Anaconda modularization
Summary
Anaconda installer will be split into several modules that will communicate over DBus using stable API.
Owner
- Name: Jiří Konečný
- Email: jkonecny@redhat.com
- Release notes owner:
Current status
- Targeted release: Fedora 28
- Last updated: 2018-01-05
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
Anaconda will be split into several modules that will communicate over DBus. The goal is to introduce a stable way to interact with Anaconda to support its customization, extensibility and testability. It will be easier to monitor the installation, maintain an install class or an addon, drop some modules or provide your own UI.
Benefit to Fedora
- Anaconda addons have stable API to work with.
- Users can create their own UI or even UI less installation.
- Anaconda modules can be enabled and disabled or even not present in the installation environment.
- Better test-ability of Anaconda.
Scope
- Proposal owners:
- Split Anaconda to modules with DBus API.
- Old UI must be modified to use new DBus API.
- Other developers:
- Thanks to the nature of how addons work right now, we need a cooperation from the Anaconda addon developers.
- Release engineering: #7240
- List of deliverables: N/A (not a System Wide Change)
- 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
User experience should be consistent with the older releases.
Dependencies
N/A (not a System Wide Change)
Contingency Plan
- Contingency mechanism: Fallback to the old (non-modular) solution will be still available during development.
- Contingency deadline: Final freeze
- Blocks release? No
Documentation
https://rhinstaller.wordpress.com/2017/10/09/anaconda-modularisation/
Most of the articles here: https://rhinstaller.wordpress.com
Release Notes
TODO