From Fedora Project Wiki
(add a footnote not to war about the actual day values at the moment) |
|||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{draft}} | {{draft}} | ||
== Introduction == | |||
The purpose of this document is to present a policy/workflow that will be used when handling package updates. It specifies when, where and which kind of package updates may occur. | |||
== Scope == | |||
* This policy concerns only [[Releases/#Current_Supported_Releases|currently supported Fedora releases]]. | |||
** ''Rules for the current pending release will be added to this document. Rules for Rawhide may come in the future.'' | |||
* Security updates that fall into the [[#Important package set|Important package set]] are subject to this policy. Security updates that do not fall into this category are not subject to this policy. | |||
== Workflows == | |||
Two workflows are defined, for different sets of packages. The sets are ''important'' packages and ''other'' packages. | |||
=== ''Important'' package set === | |||
The ''important'' package set consists of: | |||
* The current [[Critical Path Packages|critical path package set]] | |||
* All major desktop environments' core functionality (GNOME, KDE, XFCE, LXDE) | |||
* Package updating frameworks (gnome-packagekit, kpackagekit) | |||
* Major desktop productivity apps. An initial list would be firefox, kdebase (konqueror), thunderbird, evolution, kdepim (kmail). | |||
= | === ''Other'' package set === | ||
''' | The ''other'' package set consists of all packages not in the ''important'' package set. | ||
The | === ''Important'' workflow === | ||
All package updates are submitted to the 'updates-testing' repository. Then they await initial sanity test acceptance, a process owned by the [[QA|Quality Assurance]] team. Acceptance is granted according to [[#Initial requirements|Initial requirements]]. The decision is based on the result of [[User:Kparal/Proposal:Package update acceptance test plan|Package update acceptance test plan]], which is executed automatically by [[AutoQA]]. When the approval is granted, the update is pushed to the 'updates-testing' repository. | |||
Next, the updates must meet ''all'' of these requirements: | |||
* Updates must reach a specified positive Bodhi karma threshold <ref name="tbd">value to be defined</ref> provided by a defined team (e.g. ''proventesters''). These qualified testers should consider feedback (especially negative feedback) from other testers in deciding whether to provide approval, as well as their own tests. | |||
* Updates must spend some minimum amount of time <ref name="tbd"/> in updates-testing. ''This requirement does not hold for security updates.'' | |||
After submitting to 'updates' repository another round of automated [[AutoQA]] acceptance tests is run. Acceptance is granted according to [[#Stable requirements|Stable requirements]]. As a final point [[ReleaseEngineering|Release Engineering]] ensures that [[#Stable requirements|Stable requirements]] were satisfied and they sign off and push the update to 'updates'. | |||
[[Image:package_update_policy_important_workflow.png]] | |||
=== ''Other'' workflow === | |||
All package updates are submitted to the 'updates-testing' repository. Then they await initial sanity test acceptance, a process owned by the [[QA|Quality Assurance]] team. Acceptance is granted according to [[#Initial requirements|Initial requirements]]. The decision is based on the result of [[User:Kparal/Proposal:Package update acceptance test plan|Package update acceptance test plan]], which is executed automatically by [[AutoQA]]. When the approval is granted, the update is pushed to the 'updates-testing' repository. | |||
Next, the updates must meet at least ''one'' of these requirements: | |||
* Updates must reach a specified positive Bodhi karma threshold <ref name="tbd"/>. Anyone may provide karma to an update. | |||
* Updates must spend some minimum amount of time <ref name="tbd"/> in updates-testing. | |||
Proposed time would be one week, but is open to negotiation. We can track downloads with our one Fedora-infrastructure controlled mirror as mechanism to see what usage the package is getting. | |||
When at least one of the constraints is satisfied the package maintainer may submit the update to the 'updates' repository. | |||
After submitting to 'updates' repository another round of automated [[AutoQA]] acceptance tests is run. Acceptance is granted according to [[#Stable requirements|Stable requirements]]. As a final point [[ReleaseEngineering|Release Engineering]] ensures that [[#Stable requirements|Stable requirements]] were satisfied and they sign off and push the update to 'updates'. | |||
[[Image:package_update_policy_other_workflow.png]] | |||
== Initial Requirements == | |||
* '''AutoQA:''' [[Test Package Sanity]] - Packages must be able to be installed, removed, upgraded, etc. | |||
* '''AutoQA:''' Packages must not break dependencies in updates + updates-testing. | |||
* '''AutoQA:''' Packages must not introduce file/package conflicts in updates + updates-testing. | |||
* + maybe some more | |||
== Stable Requirements == | |||
* '''AutoQA:''' [[#Initial requirements|Initial requirements]] are re-checked and met. | |||
* '''AutoQA:''' Packages must not break upgrade path. | |||
* '''RelEng:''' The package update type falls into the list of [[Stable Release Updates Proposal|allowed update types]] ''(document not approved yet, just a sample)''. | |||
* + maybe some more | |||
<!-- | |||
* The result of [[User:Kparal/Proposal:Package update acceptance test plan|Package update acceptance test plan]] must be ACCEPTED. It may be NEEDS_REVIEW initially and then changed to ACCEPTED by waiving errors, that is allowed. | |||
--> | |||
== Exception Process == | |||
Package maintainers may ask for exception, when: | |||
* '' | * they don't agree with QA rejecting their update | ||
* | * they need to push an update without fully adhering to policy requirements | ||
** this is suitable for high-important bug-fix updates, which repair severe regressions/breakages | |||
** ''some other candidates?'' | |||
* they don't agree with RelEng rejecting their update | |||
''The process of asking for an exception is yet to be defined. It can be a majority vote from [[FESCo]].'' | |||
= Responsibilities = | == Responsibilities == | ||
* When a serious problem is found in a not yet released updated package, package update builder is responsible for removing this update from 'updates-testing' repository. [https://admin.fedoraproject.org/updates/ Fedora Update System] must provide this option for package update builder, package maintainer, [[QA|Quality Assurance]] team and [[ReleaseEngineering|Release Engineering]] team. | * When a serious problem is found in a not yet released updated package, package update builder is responsible for removing this update from 'updates-testing' repository. [https://admin.fedoraproject.org/updates/ Fedora Update System] must provide this option for package update builder, package maintainer, [[QA|Quality Assurance]] team and [[ReleaseEngineering|Release Engineering]] team. | ||
| Line 39: | Line 91: | ||
* The [https://admin.fedoraproject.org/updates/ Fedora Update System] is responsible for sending notifications to package update builder and package maintainer when: | * The [https://admin.fedoraproject.org/updates/ Fedora Update System] is responsible for sending notifications to package update builder and package maintainer when: | ||
** the update receives a result from [[User:Kparal/Proposal:Package update acceptance test plan|Package update acceptance test plan]] | ** the update receives a result from [[User:Kparal/Proposal:Package update acceptance test plan|Package update acceptance test plan]] | ||
** the update has fulfilled requirements for submitting into 'updates' repository | ** the update has fulfilled requirements for submitting into 'updates' repository | ||
** the update has been accepted or rejected to be pushed to 'updates' repository by [[ReleaseEngineering|Release Engineering]] team | |||
** the update becomes available in the 'updates' repository | ** the update becomes available in the 'updates' repository | ||
* Even though security updates do not fall within this policy, the [[QA|Quality Assurance]] team is still obliged to test the packages, after they're pushed if necessary, and report any regressions that need to be fixed to the maintainer. | * Even though some security updates do not fall within this policy, the [[QA|Quality Assurance]] team is still obliged to test the packages, after they're pushed if necessary, and report any regressions that need to be fixed to the maintainer. | ||
= References = | == References == | ||
<references/> | <references/> | ||
=== Related links === | === Related links === | ||
* [[UpdatePolicy(draft)]] | |||
* [[Stable Release Updates Proposal]] | |||
* [[Package update guidelines]] | * [[Package update guidelines]] | ||
* [[User:Kparal/Package update approaches]] | * [[User:Kparal/Package update approaches]] | ||
* [[Release Lifecycle(draft)]] | * [[Release Lifecycle(draft)]] | ||
Latest revision as of 15:49, 16 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.
It is still under construction and content may change. Do not rely on the information on this page.
Introduction
The purpose of this document is to present a policy/workflow that will be used when handling package updates. It specifies when, where and which kind of package updates may occur.
Scope
- This policy concerns only currently supported Fedora releases.
- Rules for the current pending release will be added to this document. Rules for Rawhide may come in the future.
- Security updates that fall into the Important package set are subject to this policy. Security updates that do not fall into this category are not subject to this policy.
Workflows
Two workflows are defined, for different sets of packages. The sets are important packages and other packages.
Important package set
The important package set consists of:
- The current critical path package set
- All major desktop environments' core functionality (GNOME, KDE, XFCE, LXDE)
- Package updating frameworks (gnome-packagekit, kpackagekit)
- Major desktop productivity apps. An initial list would be firefox, kdebase (konqueror), thunderbird, evolution, kdepim (kmail).
Other package set
The other package set consists of all packages not in the important package set.
Important workflow
All package updates are submitted to the 'updates-testing' repository. Then they await initial sanity test acceptance, a process owned by the Quality Assurance team. Acceptance is granted according to Initial requirements. The decision is based on the result of Package update acceptance test plan, which is executed automatically by AutoQA. When the approval is granted, the update is pushed to the 'updates-testing' repository.
Next, the updates must meet all of these requirements:
- Updates must reach a specified positive Bodhi karma threshold [1] provided by a defined team (e.g. proventesters). These qualified testers should consider feedback (especially negative feedback) from other testers in deciding whether to provide approval, as well as their own tests.
- Updates must spend some minimum amount of time [1] in updates-testing. This requirement does not hold for security updates.
After submitting to 'updates' repository another round of automated AutoQA acceptance tests is run. Acceptance is granted according to Stable requirements. As a final point Release Engineering ensures that Stable requirements were satisfied and they sign off and push the update to 'updates'.
Other workflow
All package updates are submitted to the 'updates-testing' repository. Then they await initial sanity test acceptance, a process owned by the Quality Assurance team. Acceptance is granted according to Initial requirements. The decision is based on the result of Package update acceptance test plan, which is executed automatically by AutoQA. When the approval is granted, the update is pushed to the 'updates-testing' repository.
Next, the updates must meet at least one of these requirements:
- Updates must reach a specified positive Bodhi karma threshold [1]. Anyone may provide karma to an update.
- Updates must spend some minimum amount of time [1] in updates-testing.
Proposed time would be one week, but is open to negotiation. We can track downloads with our one Fedora-infrastructure controlled mirror as mechanism to see what usage the package is getting.
When at least one of the constraints is satisfied the package maintainer may submit the update to the 'updates' repository.
After submitting to 'updates' repository another round of automated AutoQA acceptance tests is run. Acceptance is granted according to Stable requirements. As a final point Release Engineering ensures that Stable requirements were satisfied and they sign off and push the update to 'updates'.
Initial Requirements
- AutoQA: Test Package Sanity - Packages must be able to be installed, removed, upgraded, etc.
- AutoQA: Packages must not break dependencies in updates + updates-testing.
- AutoQA: Packages must not introduce file/package conflicts in updates + updates-testing.
- + maybe some more
Stable Requirements
- AutoQA: Initial requirements are re-checked and met.
- AutoQA: Packages must not break upgrade path.
- RelEng: The package update type falls into the list of allowed update types (document not approved yet, just a sample).
- + maybe some more
Exception Process
Package maintainers may ask for exception, when:
- they don't agree with QA rejecting their update
- they need to push an update without fully adhering to policy requirements
- this is suitable for high-important bug-fix updates, which repair severe regressions/breakages
- some other candidates?
- they don't agree with RelEng rejecting their update
The process of asking for an exception is yet to be defined. It can be a majority vote from FESCo.
Responsibilities
- When a serious problem is found in a not yet released updated package, package update builder is responsible for removing this update from 'updates-testing' repository. Fedora Update System must provide this option for package update builder, package maintainer, Quality Assurance team and Release Engineering team.
- The Fedora Update System is responsible for sending notifications to package update builder and package maintainer when:
- the update receives a result from Package update acceptance test plan
- the update has fulfilled requirements for submitting into 'updates' repository
- the update has been accepted or rejected to be pushed to 'updates' repository by Release Engineering team
- the update becomes available in the 'updates' repository
- Even though some security updates do not fall within this policy, the Quality Assurance team is still obliged to test the packages, after they're pushed if necessary, and report any regressions that need to be fixed to the maintainer.