From Fedora Project Wiki

< User:Kparal

Revision as of 16:32, 5 March 2010 by Kparal (talk | contribs) (Workflow picture again)

Warning.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.
Note.png
Use discussion
Don't forget to check discussion page.
Stop (medium size).png
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.

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

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 ACCEPTED (it may be NEEDS_REVIEW initially and then changed to ACCEPTED 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 disapprove an update according to <<FIXME - add document listing package update criteria for RelEng>>. 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 according to <<FIXME - the same document as above>>. If the approval is granted, the update is pushed to the 'updates' repository.


Package update policy workflow.png

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

References