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.
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 should go through formal review. This is mostly to check the licensing, the Fedora Packager Guidelines compliance etc.
- 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.
Step 2: build it
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 nor approval at this point.
Step 3: add it to the release
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 should go through a formal review in Bugzilla.
When asking Release Engineering to include the module in the release, the review bug is referenced.
Step 4: set / change the default
This step is about:
- setting or changing a default stream of a module
- setting or changing a default installation profile of a module
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. However, I propose that we require:
- filing a system-wide change request when changing a default stream.
- this to be allowed only in between Fedora releases, the same way as system-wide changes work now.
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. I propose that we do not require any review or approval for this.