Difference between revisions of "Pidora Package Review Process"
Chris Tyler (talk | contribs) (Created page with '== Introduction == The Pidora Package Review Process is based on the Fedora Package Review Process. The main differences are: * Pidora does no…') |
Chris Tyler (talk | contribs) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | [[Category:Pidora]][[Category:SBR600]] | ||
== Introduction == | == Introduction == | ||
| − | The Pidora Package Review Process is based on the [[:fedora:Package Review Process|Fedora Package Review Process]]. The main differences are: | + | The [[Pidora]] Package Review Process is based on the [[:fedora:Package Review Process|Fedora Package Review Process]]. The main differences are: |
* Pidora does not have a package scms or packagedb instance (yet!) | * Pidora does not have a package scms or packagedb instance (yet!) | ||
* Pidora does not have a "packager" group | * Pidora does not have a "packager" group | ||
| Line 7: | Line 8: | ||
== Pidora or Fedora? == | == Pidora or Fedora? == | ||
| − | Packages should be | + | Packages should be placed directly into Pidora only when they are not useful on any platform supported by Fedora. If a package would be useful on i386/x686, x86_64, or armv7hl, it should be added to Fedora, and will subsequently be picked up by Pidora. |
On the other hand, packages that are very specific to the Pi -- because they use Pi hardware such as the GPU or bcm2835 I2C/SPI/GPIO (and are not generalized to be useful on other development boards) -- then those packages should be packaged specifically for Pidora. | On the other hand, packages that are very specific to the Pi -- because they use Pi hardware such as the GPU or bcm2835 I2C/SPI/GPIO (and are not generalized to be useful on other development boards) -- then those packages should be packaged specifically for Pidora. | ||
Latest revision as of 00:48, 14 December 2013
Contents
Introduction
The Pidora Package Review Process is based on the Fedora Package Review Process. The main differences are:
- Pidora does not have a package scms or packagedb instance (yet!)
- Pidora does not have a "packager" group
Pidora or Fedora?
Packages should be placed directly into Pidora only when they are not useful on any platform supported by Fedora. If a package would be useful on i386/x686, x86_64, or armv7hl, it should be added to Fedora, and will subsequently be picked up by Pidora.
On the other hand, packages that are very specific to the Pi -- because they use Pi hardware such as the GPU or bcm2835 I2C/SPI/GPIO (and are not generalized to be useful on other development boards) -- then those packages should be packaged specifically for Pidora.
Package Review Request
To request a package review, prepare a bug as you would for Fedora, but place it in the Pidora/Raspberry Pi Fedora Remix [[1]] system. Additionally, note the review request on the Pidora Package Reviews page.
Package Review
To perform a package review, place your name in the reviewer column on the Pidora Package Reviews page, then perform the same steps as you would for a Fedora package review, placing the review feedback in the TRAC bug.
Package Ownership and Co-ownership Rules
To help to ensure continuity, package ownership has these conditions:
- If you are an approved, sponsored Fedora Packager, you may be the sole owner of a Pidora package
- If you are not a Fedora Packager, you need a co-owner -- one of the following:
- An approved, sponsored Fedora Packager, or
- A member of the Seneca OSTEP team
Requesting Package Ownership
After APPROVED status has been granted in the review, contact the OSTEP team at Seneca through the irc://irc.freenode.net/seneca IRC channel or by sending e-mail to ostep-team@senecacollege.ca
Note that this is roughly analogous to the "Request SCMS" step in the Fedora Packaging Process.
The OSTEP team will look over the review and then assign ownership of the package to you and your co-owner.
Building the Package
Once you have received ownership, please build the package on Koji (non-scratch) with a build target of "rpfr-XX" where XX is the next release number (e.g., rpfr-19, rpfr-20). If you have questions about doing this, please contact the OSTEP team.
