From Fedora Project Wiki
m
Line 7: Line 7:
 
The Anaconda installer used to be quite monolitic, but this is no longer the case and there is a growing trend to split parts of Anaconda to separate modules and libraries. This not only help to improve modularity, but also makes it possible to use these libraries outside of the Anaconda installer.
 
The Anaconda installer used to be quite monolitic, but this is no longer the case and there is a growing trend to split parts of Anaconda to separate modules and libraries. This not only help to improve modularity, but also makes it possible to use these libraries outside of the Anaconda installer.
  
So before contributing to Anaconda or one of its components, it is often needed to find out in which library or component the feature in question is implemented.
+
Before contributing to Anaconda or one of its components, it is often necessary to find out which library or component the feature in question is implemented.
  
 
What follows is a brief listing of the various project under the Anaconda umbrella.
 
What follows is a brief listing of the various project under the Anaconda umbrella.
Line 13: Line 13:
 
=== Anaconda ===
 
=== Anaconda ===
  
The Fedora/RHEL install itself. All installation specific code, the GUI, TUI and a lot of glue code for using the various Anaconda related modules and libraries belongs to the Anaconda project.
+
The Fedora/RHEL installer itself. All installation-specific code--the GUI, TUI and a lot of glue code--for using the various Anaconda related modules and libraries belongs to the Anaconda project.
  
 
=== pykickstart ===
 
=== pykickstart ===
Line 36: Line 36:
 
* patches can be submitted either by email or as a pull request on Github
 
* patches can be submitted either by email or as a pull request on Github
 
* all patches are reviewed by other contributors
 
* all patches are reviewed by other contributors
* if a pack has been accepted, it will be pushed to repository by one of the contributors who have commit access
+
* if a patch has been accepted, it will be pushed to the repository by a contributor who has commit access
  
 
== Filling bugs and feature requests ==
 
== Filling bugs and feature requests ==

Revision as of 19:00, 21 January 2015

Contributing to Anaconda and related projects

This wiki page aims to explain how and where to most effectively contribute to the Anaconda installer and related projects.

Not just Anaconda - choosing where to contribute

The Anaconda installer used to be quite monolitic, but this is no longer the case and there is a growing trend to split parts of Anaconda to separate modules and libraries. This not only help to improve modularity, but also makes it possible to use these libraries outside of the Anaconda installer.

Before contributing to Anaconda or one of its components, it is often necessary to find out which library or component the feature in question is implemented.

What follows is a brief listing of the various project under the Anaconda umbrella.

Anaconda

The Fedora/RHEL installer itself. All installation-specific code--the GUI, TUI and a lot of glue code--for using the various Anaconda related modules and libraries belongs to the Anaconda project.

pykickstart

blivet

libblockdev

lorax

initial setup

python-meh

Contributing code

Anaconda and all related projects are open source software and are looking forward to sensible contributions to their source code.

See the [Anaconda Patch Review Process https://fedoraproject.org/wiki/Anaconda/ReviewProcess] article for a detailed guide on submitting changes. This can be summarized as:

  • patches can be submitted either by email or as a pull request on Github
  • all patches are reviewed by other contributors
  • if a patch has been accepted, it will be pushed to the repository by a contributor who has commit access

Filling bugs and feature requests

Helping with Aanconda testing

Improving the Anaconda documentation

Translations and localization

How builds and packages are made

Contact