m (name repos correctly) |
m (once again) |
||
| Line 20: | Line 20: | ||
===== Package update testing ===== | ===== Package update testing ===== | ||
There community may test all packages in the ' | There community may test all packages in the 'updates-testing' repository. No automated testing is done. | ||
===== Package update policy ===== | ===== Package update policy ===== | ||
Revision as of 13:21, 16 February 2010
It is still under construction and content may change. Do not rely on the information on this page.
This document summarizes test plans and policies used for package updates in various Linux distributions. It is used for a quick overview and comparison when thinking about our new Fedora test plans and policies. Also a lot of links to external documents are supplied.
This document is not in any sense complete. Only those documents that were possible to find with a quick search through the public documentation are listed. Any additions and corrections are welcome.
TODO:
- add Update volume section?
Fedora
Repository separation
There is no repository separation (official/community, software freedom, etc). Available repositories are 'fedora', 'updates' and 'updates-testing'.
Initial package review
There is a package review when the package is first submitted into Fedora repositories. There are packaging and reviewing guidelines to comply with.
Future package review
There is no future package review, for any milestones nor future distribution releases.
Package update testing
There community may test all packages in the 'updates-testing' repository. No automated testing is done.
Package update policy
It is possible to submit the updated package into stable 'updates' repository immediately. The release engineering team approves these submitted packages. They have no formal definition which packages to approve and which to deny.
If the package owner wishes to test his package, he may submit it to 'updates-testing' repository. These packages are also approved by release engineering team. The owner may leave the package in this repository for arbitrary time and then submit it to stable 'updates' repository.
There is no restriction on update type (bugfix, enhancement, new package), all updates may be released. There is no definition of update release schedule, the updates are released any time.
Development release update approach
No testing repository is available for development release, everything is committed into a single repository. There is no approval process, all updates are committed immediately.
References
- https://fedoraproject.org/wiki/Category:Package_Maintainers
- https://fedoraproject.org/wiki/Packaging:Guidelines
- https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
- https://fedoraproject.org/wiki/Bodhi_Guide
- http://fedoraproject.org/wiki/Package_update_HOWTO#Submit_your_update_to_Bodhi
- http://fedoraproject.org/wiki/Package_update_guidelines
Ubuntu
Repository separation
Available repositories are 'release', '-security', '-updates', '-proposed' and '-backports'. Every repository is separated into components 'main', 'restricted', 'universe' and 'multiverse' based on software freedom and a level of official/community support.
Initial package review
There is a package review when the package is first submitted into Ubuntu repositories. There are packaging and reviewing guidelines to comply with.
Future package review
There seems to be no future package review, for any milestones nor future distribution releases.
Package update testing
The community may test all packages in the '-proposed' repository. The SRU verification team regularly tests proposed updates on different hardware. There seems to be no automated testing.
Package update policy
All updates are submitted to '-proposed' repository. Archive admins approve and publish these packages. Archive admins must conform to a formal policy. The package must stay at least 7 days in the '-proposed' repository and must be approved by SRU verification team to be pushed to stable '-updates'. Update verification must be performed by the SRU verification team for the update to get approved.
Only high-impact bugs are accepted as a reason for an update. This contains security vulnerabilities, severe regressions or bugs causing loss of user data. Updates may be also accepted for high-impact bugs that have an obviously safe patch and affect an application rather than critical infrastructure. Low-impact bug fixes, enhancements or new packages are not accepted.
I haven't found any information regarding update release schedule.
Development release update approach
No information found
References
- http://www.ubuntu.com/community/ubuntustory/components
- https://help.ubuntu.com/community/Repositories/Ubuntu#Updates%20Tab
- https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
- https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews
- https://wiki.ubuntu.com/StableReleaseUpdates
- https://wiki.ubuntu.com/ArchiveAdministration#Stable%20release%20updates
Mandriva
Repository separation
Available repositories are 'release', '-updates', '-testing' and '-backports'. Every repository is separated into components 'main', 'non-free' and 'contrib' based on software freedom and a level of official/community support.
Initial package review
No information found
Future package review
No information found
Package update testing
The community may test all packages in the '-testing' repository. Mandriva QA team validates packages from this repository before they go to '-updates' repository. There is no information about automated testing.
Package update policy
The policy concerns only 'main' component. For 'non-free' and 'contrib' component the package maintainers may upload directly to '-updates' and are only recommended with package update guidelines.
For 'main' component the '-testing' repository may be populated by package owner at any time. If the update wants to be moved to '-updates', it must conform the post-release support policy - there must be a bugzilla entry for each updated package and advisory text must be present. QA team then tests the update and validates it. Maintenance and security team then rebuilds and releases the update.
There seems to be no restriction on update type (bugfix, enhancement, new package).
I haven't found any information regarding update release schedule.
Development release update approach
No information found
References
- http://wiki.mandriva.com/en/Policies/SoftwareMedia
- http://wiki.mandriva.com/en/Policies/Support
- http://wiki.mandriva.com/en/Policies
OpenSUSE
Repository separation
Available repositories are 'oss', 'non-oss', 'update' and 'contrib'. The first two mentioned are separated based on software freedom and never change their contents. 'update' is for official security and bugfix updates. 'contrib' is used for third-party packages.
Initial package review
For 'contrib' new packages go through a review. There are packaging and review guidelines to comply with.
Future package review
No information found
Package update testing
Rpmlint is run on every package build automatically. It runs a custom configuration that scores commonly valid rpmlint warnings with a badness score, and optionally fails the build if it surpasses a threshold. The SUSE rpmlint package also contains additional checks that were written for their own use.
I haven't found any documentation about community testing.
Package update policy
For official repositories the updates must be security vulnerabilities, cause severe data loss or corruption in common configuration or be a regression to be accepted. For 'contrib' no version updates are allowed, only patches, but probably without any restriction on bugfix severity. All updates go through a review and approval of the maintenance team.
I haven't found any information regarding update release schedule.
Development release update approach
For 'contrib' no review is required to update a package. Probably the same for official repositories.
References
- http://en.opensuse.org/Package_repositories
- http://en.opensuse.org/Contrib
- http://en.opensuse.org/openSUSE:Packaging_Guidelines/Review_Guidelines
- http://en.opensuse.org/Maintenance/Policy
- http://en.opensuse.org/Maintenance
- http://en.opensuse.org/Packaging/RpmLint