From Fedora Project Wiki
(f7 is EOL)
Line 18: Line 18:
Historically we have a had a lot of stale open bugs.  In order to remain focused as a project it is best to close out bugs we aren't going to be able to resolve so that we focus on the bugs we will. This include bugs for releases that are no longer maintained and for which Fedora will never issue udpates for.
Historically we have a had a lot of stale open bugs.  In order to remain focused as a project it is best to close out bugs we aren't going to be able to resolve so that we focus on the bugs we will. This include bugs for releases that are no longer maintained and for which Fedora will never issue udpates for.


And if you think this is too aggressive you're welcome to keep your bugs alive by continually moving them to the latest version.
And if you think this is too aggressive you're welcome to keep your bugs alive by continually moving them to the latest version.  Or if they are unimplemented features set them to version: ''rawhide'' and add the keyword ''FutureFeature''.


== Bugzilla Product Versioning ==
== Bugzilla Product Versioning ==

Revision as of 00:30, 15 August 2008

Bugzilla Maintenance SOP

Review & Approval Process

This proposal was circulated for review for a period of three weeks on the Fedora lists and reviewed and approved by FESCo on 2008-03-20

Background

The following page outlines the process for managing open Fedora bugs during the release process. We intend to proactively manage unresolved bugzillas in a systematic orderly way which will introduce predictability to the bugzilla maintenance cycle. We also do not want to disenfranchise one of our most valuable community resources: bug reporters.

Historically we have a had a lot of stale open bugs. In order to remain focused as a project it is best to close out bugs we aren't going to be able to resolve so that we focus on the bugs we will. This include bugs for releases that are no longer maintained and for which Fedora will never issue udpates for.

And if you think this is too aggressive you're welcome to keep your bugs alive by continually moving them to the latest version. Or if they are unimplemented features set them to version: rawhide and add the keyword FutureFeature.

Bugzilla Product Versioning

  • Fedora will track bugs solely based on the version number of the release or rawhide: the release under development which has not been released.
  • Fedora will not create separate fedora versions in bugzilla for individual test releases, including, but not limited to: alpha, beta, preview release, etc. Fedora has tried this structure in the past, but found it difficult to maintain and its benefit imperceptible.
  • Changes to this policy require review and approval by FESCo.

Rawhide bug handling

  • Rawhide is a unique version number in that it refers to the current release under development. At or around the final release of a release under development, bugs assigned to the rawhide version will be rebased to the final release version.
  • For example, after the final release of Fedora 8, all newly reported bugs found in development packages for Fedora 9 are reported against rawhide. At or around the final release of Fedora 9, all rawhide bugs will have their version changed, or rebased to be "9".
  • It is important to rebase rawhide bugs each release cycle to maintain some idea as to which development cycle they were associated with. Otherwise cleanup processes, like the one performed during the Fedora 9 cycle are necessary, to take a rough stab at determining which rawhide bugs belong to EOL releases that should be closed.
  • Rebasing rawhide bugs each release cycle also provides information on how many bugs are filed during a given development cycle.

Tracker Bugs

  • Fedora creates a series of tracker bugs at the beginning of each new release cycle (1 day after GA of the previous release). The official tracker bugs are:
  1. Alpha
  2. Beta
  3. Preview Release
  • Also, the day after release, GA blocker and GA target bugs are created for release N+2. For example, at the release of Fedora 9, Fedora 11 Target and Blocker bugs were created. At the release of Fedora 10, Fedora 12 blocker and target bugs will be created, etc.
  • A list of tracker bugs is maintained at this page: here
Tracker bugs--commonly referred to as blocker bugs--are meta-bugs used to monitor a group of bugs that must be resolved before a specific release milestone and are therefore considered to block the release.

Currently Supported Versions

  • Fedora 9: EOL one month after GA of Fedora 11 (roughly May 1, 2009)
  • Fedora 8: EOL one month after GA of Fedora 10 (roughly November 30, 2008)
  • All other versions of Fedora are unmaintained and thus End Of Life (EOL).
An unmaintained release receives no maintenance or updated packages. Therefore bugs are not tracked against these releases. In the future we will seek an enhancement to bugzilla to disable the ability to file bugs against unmaintained versions as there is no value in doing so.

Release Processes

The following sections talk about submitting tickets to Red Hat Engineering Operations and running scripts. The overarching idea here is to have standardized processes and scripts to complete these tasks each release. The scripts have been written, the names are referred to for sake of example. Red Hat Engineering Operations maintains Fedora's bugzilla.

First Day of Development

  • Create tracker bugs for test releases and GA of next release
  • Flush BugZappers/ActiveTriagers page and make way for the new triagers for the next release
  • There are no term limits, but we want to flush the page each release so it stays current without a lot of work. We don't think asking people to re-add their names once every six months is a big deal.
  • Send out announcement to fedora-test-list@redhat.com asking triagers for next release to add their names

Two Weeks Before Release Date

  • File a ticket with Red Hat Engineering Operations requesting advanced preparation for the following:
  1. Creation of a new Fedora version the day before release day
  2. Ready the rawhide-mover script for mass-change of all bugs currently open against the rawhide version to be mass moved to the new Fedora version
    • For example all rawhide bugs open up until the official release of Fedora 9 will be changed to version 9 from rawhide.
    • All bugs with component == "package review" will remain rawhide
    • All bugs on trackers for the next release will remain rawhide. For example, at GA of Fedora 10, bugs which are blocking either F11Target or F11Blocker will not be moved.
    • All bugs with the 'noauto' text in the Status Whiteboard field will be ignored. Please note that these will, however, be subject to manual scrutiny for continued applicability at each release.
  3. Update text that refers to the latest Fedora version on these pages (coordinate wording with marketing):
    1. https://bugzilla.redhat.com/
    2. https://bugzilla.redhat.com/enter_bug.cgi
  4. Create/update script eol-warning script for mass-change of all bugs for the oldest supported version which will become end of life (EOL) one month from GA date
    1. DECIDE: Should these bugs be put in special state or tagged in some way (e.g. keyword)?
    2. include text explaining that:
      1. one month of support remains
      2. please attempt to reproduce on most recent version of Fedora released which is: FIXME
      3. if you discover this bug is present in the most recent version please change the version to that release
      4. if you are using this bug for other purposes and wish for it to remain open, change it to the latest Fedora version to avoid auto-closure
      5. if this bug remains open on: FIXME it will automatically be CLOSED:WONTFIX
  5. Create/update script eol-closer script for mass-change of all OPEN bugs for the release which will become unmaintained (EOL). The script when run will:
    1. change status to CLOSED WONTFIX
    2. include text explaining that:
      1. this release is no longer supported--an updated package will not be created. As a project we are only capable of supporting two releases at a time and there for our efforts are focused on currently supported versions.
      2. we would still appreciate your help if you could attempt to reproduce this bug on the latest supported version which is: FIXME or latest test release for the version under development which is: FIXME . If issue still exists, please change the bugzilla version to reflect where you reproduced the issue and reopen the bug with a status of NEW.
      3. standard wording will be maintained on at the Bugzappers/BugzillaBoilerPlate (TODO: CREATE) page

One Week Before Release Date

  1. Ready the eol-warning script for mass-change of all bugs for the oldest supported version which will become end of life (EOL) one month from GA date:
    1. select all bugs !CLOSED (any status except CLOSED)
    2. select all bugs open for the version becoming EOL
    3. include text explaining that:
      1. one month of support remains
      2. please attempt to reproduce on most recent version of Fedora which was just released and is: ____. If the issue still exists, please change the bugzilla version to reflect the current version and note the package NVR.
      3. if this bug remains open on: _____ (date of EOL) it will automatically be closed as WONTFIX
      4. standard wording will be maintained on at the Bugzappers/BugzillaBoilerPlate (TODO: CREATE) page

One Day Before Release Date

  1. Confirm that release day is for sure with release engineering.
  2. Enable new version in Bugzilla
  3. Request execution of rawhide-mover-script

Day of Release

  1. Run eol-warning script
  2. File a ticket with Red Hat Engineering Operations requesting advanced preparation of the eol-closer script for mass-change of all bugs for versions which are which are EOL
    • DECIDE: Should these bugs be put in special state or tagged in some way (e.g. keyword)?
    • include text explaining that:
    1. one month of support remains
    2. please attempt to reproduce on most recent version of Fedora released which is: ____
    3. if this bug remains open on: _____ (date of EOL) it will automatically be closed as WONTFIX
  3. Run a quick query for all bugs that are !CLOSED (any state except CLOSED) for all release which have reached End of Life (EOL).
    1. Add boilerplate text explaining that it is Fedora's policy that all bugs all EOL releases remain in CLOSED state. Also encourage the reporter to attempt to reproduce the bug against the latest maintained version of Fedora
    2. Change status of bug to CLOSED.
    3. standard wording will be maintained on at the Bugzappers/BugzillaBoilerPlate (TODO: CREATE) page

One Month after GA Release

  1. Confirm EOL date with: FIXME
  2. Run eol-closer script
  3. Update this page with correct maintained and EOL Fedora versions
  4. Update Bugzappers/BugzillaBoilerPlate (TODO: CREATE) page with correct maintained and EOL Fedora versions

Ongoing

  1. Monitor all bugs that are !CLOSED (any state except CLOSED) for all release which are no longer maintained have reached End of Life (EOL).
  2. Monitor and triage all bugs for currently maintained and rawhide releases which have a bugzilla status of NEW or have been in status of NEEDINFO for greater than thirty (30) days. See bug life cycle for more information and policies.

Bugzilla Script Lexicon

  1. rawhide-mover mass moves all bugs currently open against the rawhide version to the latest released Fedora version
  2. eol-warning posts a warning to all bugs for the oldest supported version (GA minus 2) which will become end of life (EOL) one month after the GA date
  3. eol-closer closes all bugs for release becoming EOL
Retrieved from "https://fedoraproject.org/w/index.php?title=BugZappers/HouseKeeping&oldid=45091"