From Fedora Project Wiki
(add a footnote not to war about the actual day values at the moment) |
(RelEng approval is no longer needed for pushing to updates-testing) |
||
| Line 19: | Line 19: | ||
= Workflow = | = Workflow = | ||
All package updates are submitted to the 'updates-testing' repository. | All package updates are submitted to the 'updates-testing' repository. Then they await [[QA|Quality Assurance]] team approval. QA team approval is granted according to [[#QA Acceptance Review guidelines|QA Acceptance Review guidelines]]. When the approval is granted, the update is pushed to the 'update-testing' repository. | ||
The package updates must spend at least 14 days <ref name="value">The actual values here are the most easily changeable part of the proposal. They don't deserve a heated discussion at the moment.</ref> in the 'updates-testing' repository, or at least 7 days <ref name="value"/> provided they have karma of at least 3 <ref name="value"/> and no negative feedback. Only after that the package maintainer may submit them to the 'updates' repository. The [[ReleaseEngineering|Release Engineering]] team may approve or disapprove such an update according to [[#RelEng Acceptance Review guidelines|RelEng Acceptance Review guidelines]]. If the approval is granted, the update is pushed to the 'updates' repository. | The package updates must spend at least 14 days <ref name="value">The actual values here are the most easily changeable part of the proposal. They don't deserve a heated discussion at the moment.</ref> in the 'updates-testing' repository, or at least 7 days <ref name="value"/> provided they have karma of at least 3 <ref name="value"/> and no negative feedback. Only after that the package maintainer may submit them to the 'updates' repository. The [[ReleaseEngineering|Release Engineering]] team may approve or disapprove such an update according to [[#RelEng Acceptance Review guidelines|RelEng Acceptance Review guidelines]]. If the approval is granted, the update is pushed to the 'updates' repository. | ||
Revision as of 14:30, 9 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.
Use discussion
Don't forget to check discussion page.
Don't forget to check discussion page.
.png){kind=small}
This is just a proposal
Please bear in mind that this is just a draft meant to provoke discussion. Nothing is rock-solid here and it is not an attempt of the QA team to Fedora project domination.
Please bear in mind that this is just a draft meant to provoke discussion. Nothing is rock-solid here and it is not an attempt of the QA team to Fedora project domination.
Introduction
This proposal has not yet been announced to public, because we want to have it in some solid shape first.
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 need not to follow this policy as the Security Response Team can bypass it to have the updates released as soon as possible.
Workflow
All package updates are submitted to the 'updates-testing' repository. Then they await Quality Assurance team approval. QA team approval is granted according to QA Acceptance Review guidelines. When the approval is granted, the update is pushed to the 'update-testing' repository.
The package updates must spend at least 14 days [1] in the 'updates-testing' repository, or at least 7 days [1] provided they have karma of at least 3 [1] and no negative feedback. Only after that the package maintainer may submit them to the 'updates' repository. The Release Engineering team may approve or disapprove such an update according to RelEng Acceptance Review guidelines. If the approval is granted, the update is pushed to the 'updates' repository.
QA Acceptance Review guidelines
- TODO
- The guidelines items which might be automated are implemented in Package update acceptance test plan. The result of this test plan must be ACCEPTED (it may be NEEDS_REVIEW initially and then changed to ACCEPTED by waiving warnings, that is allowed).
RelEng Acceptance Review guidelines
- TODO
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
- approval is granted or refused by Release Engineering team (both when submitting to 'updates-testing' or 'updates' repository)
- the update has fulfilled requirements for submitting into 'updates' repository
- the update becomes available in the 'updates' repository
- Even though 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.