mNo edit summary |
No edit summary |
||
Line 8: | Line 8: | ||
The process has four main steps: | The process has four main steps: | ||
new repositories --> build it --> add it to the release --> set / change the default | '''new repositories''' --> '''build it''' --> '''add it to the release''' --> '''set / change the default''' | ||
=== Step 1: new repositories === | === Step 1: new repositories === | ||
This step includes creating new repositories or branches in dist-git for both RPM packages and modules. | This step includes creating new repositories or branches in dist-git for both RPM packages and modules. | ||
==== How ==== | |||
'''Packages''' should be handled the same way as they are now. That means: | '''Packages''' should be handled the same way as they are now. That means: | ||
Line 25: | Line 27: | ||
Of course, to request any repositories in the dist-git, one needs to be a Fedora packager. | Of course, to request any repositories in the dist-git, one needs to be a Fedora packager. | ||
==== What ==== | |||
'''Packages:''' Follow the [[Package_Review_Process#Contributor|Package Review Process for Contributors]]. | |||
'''Modules:''' TBD (either filing a ticket somewhere, or using the fedrepo-req tool) | |||
=== Step 2: build it === | === Step 2: build it === | ||
==== How ==== | |||
This step is about submitting a module build to the Fedora infrastructure. The resulting binaries will not be included in any release in this step. Anyone who is a Fedora packager should be able to build modules they own. There is no review or approval at this point. | This step is about submitting a module build to the Fedora infrastructure. The resulting binaries will not be included in any release in this step. Anyone who is a Fedora packager should be able to build modules they own. There is no review or approval at this point. | ||
==== What ==== | |||
Use the ''fedpkg module-build'' command inside your local copy of the module dist-git repository. | |||
=== Step 3: add it to the release === | === Step 3: add it to the release === | ||
==== How ==== | |||
In order to make a module available to the end user, it needs to be released. Technically, this means including the module in a compose. | In order to make a module available to the end user, it needs to be released. Technically, this means including the module in a compose. | ||
Line 37: | Line 53: | ||
When asking Release Engineering to include the module in the release, the review bug is referenced. | When asking Release Engineering to include the module in the release, the review bug is referenced. | ||
==== What ==== | |||
TBD | |||
=== Step 4: set / change the default === | === Step 4: set / change the default === | ||
==== How ==== | |||
Setting or changing a '''default stream''' of a module is in most cases similar to changing a major version of a package. An exception to this is setting a default stream of a new module which does not replace any packages in the base. Setting or changing the default stream requires a [[Changes/Policy|Fedora Change]] request when, and is only allowed in between Fedora releases. | Setting or changing a '''default stream''' of a module is in most cases similar to changing a major version of a package. An exception to this is setting a default stream of a new module which does not replace any packages in the base. Setting or changing the default stream requires a [[Changes/Policy|Fedora Change]] request when, and is only allowed in between Fedora releases. | ||
On the other hand, changing a '''default installation profile''' does not affect any other packages, as the package set that is available is still the same. No change request is required for this. | On the other hand, changing a '''default installation profile''' does not affect any other packages, as the package set that is available is still the same. No change request is required for this. | ||
==== What ==== | |||
TBD |
Revision as of 10:13, 15 March 2018
This proposal describes the processes for:
- adding new modules (and packages that are part of these modules) to Fedora including dist-git repository requests and reviews
- managing default module streams in Fedora
The process
The process has four main steps:
new repositories --> build it --> add it to the release --> set / change the default
Step 1: new repositories
This step includes creating new repositories or branches in dist-git for both RPM packages and modules.
How
Packages should be handled the same way as they are now. That means:
- When adding a new package (creating a new dist-git repository), the package goes through the Package Review Process. This is to check the compliance with the Fedora Packaging Guidelines.
- When adding a new branch to an existing package, no formal review is necessary.
Repositories and branches for modules should not require any review. This is because:
- At this point, modules are not included in any release.
- Modules themselves do not provide any content. New content is provided by packages that need to pass a review.
Of course, to request any repositories in the dist-git, one needs to be a Fedora packager.
What
Packages: Follow the Package Review Process for Contributors.
Modules: TBD (either filing a ticket somewhere, or using the fedrepo-req tool)
Step 2: build it
How
This step is about submitting a module build to the Fedora infrastructure. The resulting binaries will not be included in any release in this step. Anyone who is a Fedora packager should be able to build modules they own. There is no review or approval at this point.
What
Use the fedpkg module-build command inside your local copy of the module dist-git repository.
Step 3: add it to the release
How
In order to make a module available to the end user, it needs to be released. Technically, this means including the module in a compose.
At this point, the module goes through the Module Review Process.
When asking Release Engineering to include the module in the release, the review bug is referenced.
What
TBD
Step 4: set / change the default
How
Setting or changing a default stream of a module is in most cases similar to changing a major version of a package. An exception to this is setting a default stream of a new module which does not replace any packages in the base. Setting or changing the default stream requires a Fedora Change request when, and is only allowed in between Fedora releases.
On the other hand, changing a default installation profile does not affect any other packages, as the package set that is available is still the same. No change request is required for this.
What
TBD