It is still under construction and content may change. Do not rely on the information on this page.
Don't forget to check discussion page.
.png){kind=small}
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. This is a combination of the QA team's proposal and Bill Nottingham's proposal.
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 need not to follow this policy as the Security Response Team can bypass it to have the updates released as soon as possible.
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 QQuality Assurance team. FIXME: this is the filter point for really basic automated sanity tests - dependency sanity, major packaging errors. Acceptance is granted according to 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 package updates must be tested and approved by the QA or Release Engineering teams. Approval consists of a +1 vote in Bodhi. Qualified testers should consider feedback from other testers in deciding whether to provide approval, especially negative feedback, as well as their own tests. Only after that the package maintainer may push the update to the 'updates' repository.
Other workflow
Maintainers may choose to submit updates to the 'updates-testing' or directly to the 'updates' repository. Whichever repository is chosen, the update must pass the same initial sanity tests as in the Important workflow. If an update sent to 'updates-testing' has passed the sanity tests, the maintainer may push it to the 'updates' repository at any time. Maintainers are encouraged, but not required, to request additional review from the QA group or other testers and to consider the feedback in choosing whether to push the update.
Requirements
- TODO
- Here will be the list of requirements the package update must pass. Different teams (RelEng, QA) will probably add their own specific suggestions.
- The result of 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 shorten time required for an update to spend in 'updates-testing'
- this is allowed 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.
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.
References