User:Kparal/Package update approaches

From FedoraProject

< User:Kparal
Revision as of 19:35, 11 February 2010 by Kparal (Talk | contribs)

Jump to: navigation, search
Warning (medium size).png
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 Debian
  • add Update volume section?

Contents

Fedora

Repository separation

There is no repository separation (official/community, software freedom, etc). Available repositories are 'release', '-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 alsp 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

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

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