User:Kparal/Proposal:Package update policy

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

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. It also specifies what happens to the package updates they are evaluated as PASSED, FAILED or NEEDS_INSPECTION, as per Package update acceptance test plan.

Scope

• This policy concerns only currently supported Fedora releases.
  • Should we define also policies for Rawhide and for pending release?
• This policy is recommended also for security updates, but Security Response Team may choose not to follow it.
  • Should we specify that Bodhi must be able to provide an option to Security Response Team to bypass implemented Package update policy workflow?

Workflow

All package updates are submitted to the 'updates-testing' repository. First they await Quality Assurance team approval. QA team approval is granted through Package update acceptance test plan, whose result for the particular update must be PASSED (it may be NEEDS_REVIEW initially and then changed to PASSED by waiving warnings, this is allowed). Then Release Engineering team approval is needed. Generally all kinds of updates are permitted (bugfixes, enhancements, new upstream versions, brand new packages), but the Release Engineering team may decide differently for some package updates. When both approvals are granted, the update is pushed to the 'update-testing' repository.

The package updates must spend at least 14 days in the 'updates-testing' repository, or at least 7 days provided they have karma of at least 3 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. If the approval is granted, the update is pushed to the 'updates' repository.

• Should RelEng have some formal definition which requests to approve and which to disapprove? Should even the RelEng ACK be there? Do they even reject anything some time? And for which reason?

Update release schedule

• The 'updates-testing' repository is updated continuously, it is refreshed for every package update.
• The 'updates' repository is updated regularly once a week for regular updates and continuously for security updates.
  • Will that help us improve quality by having updates as a weekly "pack" (with possible interactions and collisions, etc) instead of continuous stream of single updates?
• By default the end-user is notified once in a fortnight for regular updates and daily for security updates.
  • This may fall into other policy than Package update policy?

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 other than PASSED from Package update acceptance test plan
    • Maybe let's inform even on PASSED? Even in this case the maintainer may see some advisory warnings he would like to fix and withdraw the package from 'updates-testing'.
  • 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