From Fedora Project Wiki
m (once again)
(update the MDV section with some extra info)
 
Line 78: Line 78:


===== Initial package review =====
===== Initial package review =====
No information found
There's no formal package review system. Packaging privileges are granted on an informal basis by a few people with powers to do so. Some people are granted access only to contrib, others to all repos. Packagers can introduce new packages to repos to which they have access at any time with no formal review (there are some people who watch the SVN commit logs and will notice+remark broken or ill-advised new package introductions, though.)


===== Future package review =====
===== Future package review =====
No information found
Ditto above, no formal ongoing review.


===== Package update testing =====
===== 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.
The community may test all packages in the '-testing' repository. Mandriva security team validates packages from this repository before they go to '-updates' repository. Security/QA team has some informal scripts for automated testing, and all MDV package submissions have to pass a modified rpmlint test (certain rpmlint tests are marked as critical, and if a package submission fails these, it will be refused by the buildsystem with an advisory email to the submitter).


===== Package update policy =====
===== 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.
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.
For 'main' component the '-testing' repository may be populated by package owner at any time (though by policy it is intended only to be used for packages which are ultimately meant to go in /updates). 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 (there is a formal process for doing this on the Bugzilla ticket). Maintenance and security team then rebuilds and releases the update.


There seems to be no restriction on update type (bugfix, enhancement, new package).
Updates are supposed to be done only to fix significant bugs or security issues. 'Enhancement' updates are generally not issued by Mandriva, nor are 'new package' updates except where a new package is required to ship a necessary update for an existing package. 'Enhancement' and 'new package' updates are intended to go to the backports repository.


I haven't found any information regarding update release schedule.
There is no particular update release schedule, updates are pushed on a 'best effort' basis by the security team.


===== Development release update approach =====
===== Development release update approach =====
No information found
 
Almost everything goes directly into the Cooker -release repository, but it is possible to use the Cooker -testing repository for particularly potentially dangerous updates, and maintainers will periodically do this, with a note on the cooker mailing list to alert people (most Cooker users don't habitually check -testing).


===== References =====
===== References =====

Latest revision as of 06:01, 2 March 2010

This page is a draft only
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

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

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

There's no formal package review system. Packaging privileges are granted on an informal basis by a few people with powers to do so. Some people are granted access only to contrib, others to all repos. Packagers can introduce new packages to repos to which they have access at any time with no formal review (there are some people who watch the SVN commit logs and will notice+remark broken or ill-advised new package introductions, though.)

Future package review

Ditto above, no formal ongoing review.

Package update testing

The community may test all packages in the '-testing' repository. Mandriva security team validates packages from this repository before they go to '-updates' repository. Security/QA team has some informal scripts for automated testing, and all MDV package submissions have to pass a modified rpmlint test (certain rpmlint tests are marked as critical, and if a package submission fails these, it will be refused by the buildsystem with an advisory email to the submitter).

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 (though by policy it is intended only to be used for packages which are ultimately meant to go in /updates). 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 (there is a formal process for doing this on the Bugzilla ticket). Maintenance and security team then rebuilds and releases the update.

Updates are supposed to be done only to fix significant bugs or security issues. 'Enhancement' updates are generally not issued by Mandriva, nor are 'new package' updates except where a new package is required to ship a necessary update for an existing package. 'Enhancement' and 'new package' updates are intended to go to the backports repository.

There is no particular update release schedule, updates are pushed on a 'best effort' basis by the security team.

Development release update approach

Almost everything goes directly into the Cooker -release repository, but it is possible to use the Cooker -testing repository for particularly potentially dangerous updates, and maintainers will periodically do this, with a note on the cooker mailing list to alert people (most Cooker users don't habitually check -testing).

References

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

Debian

References
Retrieved from "https://fedoraproject.org/w/index.php?title=User:Kparal/Package_update_approaches&oldid=156788"