From Fedora Project Wiki
mNo edit summary
mNo edit summary
Line 16: Line 16:
'''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:


* 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 package (creating a new dist-git repository), the package goes through the [[Package Review Process]]. This is to check the compliance with the [[Packaging:Guidelines|Fedora Packaging Guidelines]].
* When adding a new branch to an existing package, no formal review is necessary.
* When adding a new branch to an existing package, no formal review is necessary.


Line 34: Line 34:
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.


At this point, the module should go through a '''formal review''' in Bugzilla.
At this point, the module goes through the [[Module:Review Process|Module Review Process]].


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.
Line 40: Line 40:
=== Step 4: set / change the default ===
=== Step 4: set / change the default ===


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:
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.


* filing a '''system-wide change''' request when changing a default stream.
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.
* 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.

Revision as of 16:09, 14 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.

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.

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 or 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 goes through the Module Review Process.

When asking Release Engineering to include the module in the release, the review bug is referenced.

Step 4: set / change the default

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.