Revision as of 21:36, 15 September 2008

Fedora Bugzilla Maintenance SOP

This page and the associated pages explain the processes Fedora uses to manage http://bugzilla.redhat.com as it relates to the Fedora product. These processes were created based on Fedora's past experiences and anticipated future needs.

Task Breakdown

Tasks to make sure the bug handling policies listed below run smoothly are grouped by when they take place. These tasks are also included in the comprehensive Fedora release schedule.

Versioning

Fedora tracks bugs solely based on the version number of the release or rawhide
- rawhide always refers the release currently under development which has not been released or reached GA (general availability)
Fedora does not create separate fedora versions in bugzilla for individual test releases, including, but not limited to: alpha, beta, and preview releases.
- Fedora tried this structure in the past, but it provided very little benefit and was difficult to maintain and use consistently.
The new version number for the next Fedora release is added to Bugzilla on the day of general availability (GA).
Changes to this policy require review and approval by FESCo.

Rawhide Version

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 are rebased (changed) to the final release version.
- For example, after the final release of Fedora 22, all newly reported bugs found in development packages for Fedora 22 are reported against rawhide. At or around the final release of Fedora 22, all rawhide bugs which are not new features will have their version changed, or rebased to be "22".
Rebasing rawhide bugs each release cycle helps to keep bugs linked with the release (development cycle) they were found in.
- Historically this was a problem because rawhide bugs weren't included in the EOL process and remained open indefinitely.
- Rebasing rawhide bugs each release cycle also provides an idea of how many bugs are filed during a given development cycle.

Rawhide Bugs Excluded From Rebase

Feature requests or Requests for Enhancement (RFEs)
- Feature requests or RFEs are designated by the FutureFeature keyword
Package Review requests opened against the rawhide version are not rebased.
- Package Review bugs are filed and identified by the Package Review component

Tracker (Blocker) Bugs

Tracker, sometimes referred to as blocker, bugs are single bugs used to keep track of several other related bugs. Fedora generally uses tracker bugs to keep track of bugs that need to be fixed during key milestones in the development process. The BugZappers are responsible for creating the following tracker bugs for each release:

Alpha--must be fixed prior to releasing Alpha Release
Beta--must be fixed prior to release Beta Release
Preview--must be fixed prior to release Preview Release
Target--good to fix if possible by GA, but not required
Blocker--must be fixed prior to General Availability (GA)

Everyone who reports or reviews bugs is reponsible for seeing that applicable bugs are added to the appropriate tracker.
See Tracking Bugs for a listing of the current tracker bugs and process around creating them.

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.

End of Life (EOL)

Releases for which updates are no longer provided are considered to beunmaintained and thus End of Life or commonly referred to as EOL. Fedora does not track or review bugs for releases where there will be no more updates.
See release life cycle for more information about how long releases are maintained and list of releases with their current status.

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.

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

@@ Line 1: / Line 1: @@
-= Bugzilla Maintenance SOP =
+= Fedora Bugzilla Maintenance SOP =
+This page and the associated pages explain the processes Fedora uses to manage http://bugzilla.redhat.com as it relates to the ''Fedora'' product.  These processes were created based on Fedora's past experiences and anticipated future needs.
-== Review & Approval Process ==
+== Task Breakdown ==
-* http://www.redhat.com/archives/fedora-devel-list/2008-March/msg00881.html
-* http://www.redhat.com/archives/fedora-devel-list/2008-March/msg01199.html
-* http://www.redhat.com/archives/fedora-devel-announce/2008-March/msg00005.html
-* http://jstanley.fedorapeople.org/meetings/bugzapper0312.txt
-* http://bpepple.fedorapeople.org/fesco/FESCo-2008-03-13.html
-* http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080320
-* http://bpepple.fedorapeople.org/fesco/FESCo-2008-03-20.html
-* http://www.redhat.com/archives/fedora-test-list/2008-March/msg00834.html
-{{Admon/note | 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 ==
+Tasks to make sure the bug handling policies listed below run smoothly are grouped by when they take place.  These tasks are also included in the comprehensive Fedora release schedule.
-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.
+* [[BugZappers/HouseKeeping/FirstDayDevel | First Day of Development]]
+* [[BugZappers/HouseKeeping/FourWeeksBeforeRelease |Four Weeks Before Release Date ]]
+* [[BugZappers/HouseKeeping/TwoWeeksBeforeRelease |Two Weeks Before Release Date ]]
+* [[BugZappers/HouseKeeping/WeekBeforeRelease |One Week Before Release Date ]]
+* [[BugZappers/HouseKeeping/DayBeforeRelease | One Day Before Release Date ]]
+* [[BugZappers/HouseKeeping/ReleaseDay | Day of Release (GA) ]]
+* [[BugZappers/HouseKeeping/MonthAfterRelease  |One Month after GA Release ]]
+* [[BugZappers/HouseKeeping/OnGoing | Ongoing ]]
-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''.
+== Versioning ==
+* Fedora tracks bugs solely based on the version number of the release or ''rawhide''
-== Bugzilla Product Versioning ==
+** ''rawhide'' always refers the release currently under development which has not been released or reached GA (general availability)
-* 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 does '''not''' create separate ''fedora versions'' in bugzilla  for individual test releases, including, but not limited to: alpha, beta, and preview releases.
-* 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.
+** Fedora tried this structure in the past, but it provided very little benefit and was difficult to maintain and use consistently.
+* The new version number for the next Fedora release is added to Bugzilla on the day of general availability (GA).
 * Changes to this policy require review and approval by FESCo.
-== Rawhide bug handling ==
+== Rawhide Version ==
-* ''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.
+* ''Rawhide'' is a unique version number in that it refers to the current release under development.
-* 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".
+* At or around the final release of a release under development, bugs assigned to the ''rawhide'' version are rebased (changed) to the final release version.
-* 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.
+** For example, after the final release of Fedora 22, all newly reported bugs found in development packages for Fedora 22 are reported against rawhide.  At or around the final release of Fedora 22, all rawhide bugs which are not new features will have their version changed, or ''rebased'' to be "22".
-* Rebasing ''rawhide'' bugs each release cycle also provides information on how many bugs are filed during a given development cycle.
+* Rebasing rawhide bugs each release cycle helps to keep bugs linked with the release (development cycle) they were found in.
+** Historically this was a problem because ''rawhide'' bugs weren't included in the EOL process and remained open indefinitely.
+** Rebasing ''rawhide'' bugs each release cycle also provides an idea of how many bugs are filed during a given development cycle.
+=== Rawhide Bugs Excluded From Rebase ===
+* Feature requests or ''Requests for Enhancement'' (RFEs)
+** Feature requests or RFEs are designated by the <code>FutureFeature</code> keyword
+* Package Review requests opened against the ''rawhide'' version are not rebased.
+** Package Review bugs are filed and identified by the ''Package Review'' component
-== Tracker Bugs ==
+== Tracker (Blocker) 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:
-# Alpha
-# Beta
-# 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.
+Tracker, sometimes referred to as ''blocker'', bugs are single bugs used to keep track of several other related bugs.  Fedora generally uses tracker bugs to keep track of bugs that need to be fixed during key milestones in the development process.  The BugZappers are responsible for creating the following tracker bugs for each release:
+# Alpha--must be fixed prior to releasing Alpha Release
+# Beta--must be fixed prior to release Beta Release
+# Preview--must be fixed prior to release Preview Release
+# Target--good to fix if possible by GA, but not required
+# Blocker--must be fixed prior to General Availability (GA)
-* A list of tracker bugs is maintained at this page: [https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Fedora&version=&component=&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=FAILS_QA&bug_status=RELEASE_PENDING&bug_status=POST&bug_status=PASSES_QA&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&fixed_in_type=allwordssubstr&fixed_in=&qa_whiteboard_type=allwordssubstr&qa_whiteboard=&keywords_type=allwords&keywords=Tracking&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= here]
+* Everyone who reports or reviews bugs is reponsible for seeing that applicable bugs are added to the appropriate tracker.
+* See [[BugZappers/HouseKeeping/Trackers| Tracking Bugs]] for a listing of the current tracker bugs and process around creating them.
 {{Admon/note | ''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 ==
+== End of Life (EOL) ==
-* 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)
+* Releases for which updates are no longer provided are considered to be''unmaintained'' and thus ''End of Life'' or commonly referred to as ''EOL''.  Fedora does not track or review bugs for releases where there will be no more updates.
-* All other versions of Fedora are ''unmaintained'' and thus ''End Of Life'' (EOL).
+* See [[LifeCycle| release life cycle]] for more information about how long releases are maintained and list of releases with their current status.
 {{Admon/note | 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 ==
+== SOP Review & Approval Process ==
-{{Admon/note | 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.}}
+* http://www.redhat.com/archives/fedora-devel-list/2008-March/msg00881.html
+* http://www.redhat.com/archives/fedora-devel-list/2008-March/msg01199.html
+* http://www.redhat.com/archives/fedora-devel-announce/2008-March/msg00005.html
+* http://jstanley.fedorapeople.org/meetings/bugzapper0312.txt
+* http://bpepple.fedorapeople.org/fesco/FESCo-2008-03-13.html
+* http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080320
+* http://bpepple.fedorapeople.org/fesco/FESCo-2008-03-20.html
+* http://www.redhat.com/archives/fedora-test-list/2008-March/msg00834.html
-=== First Day of Development ===
+{{Admon/note | 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}}
-* 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:
-# Creation of a new Fedora version the day before release day
-# 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.
-# Update text that refers to the latest Fedora version on these pages (coordinate wording with marketing):
-## https://bugzilla.redhat.com/
-## https://bugzilla.redhat.com/enter_bug.cgi
-# 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
-## '''DECIDE''': Should these bugs be put in special state or tagged in some way (e.g. keyword)?
-## include text explaining that:
-### one month of support remains
-### please attempt to reproduce on most recent version of Fedora released which is: '''FIXME'''
-### if you discover this bug is present in the most recent version please change the version to that release
-### 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
-### if this bug remains open on: '''FIXME''' it will automatically be ''CLOSED:WONTFIX''
-# 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:
-## change status to CLOSED WONTFIX
-## include text explaining that:
-### 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.
-### 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.
-### standard wording will be maintained on at the Bugzappers/BugzillaBoilerPlate ('''TODO: CREATE''') page
-=== One Week Before Release Date ===
-# 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:
-## select all bugs !CLOSED (any status except CLOSED)
-## select all bugs open for the version becoming EOL
-## include text explaining that:
-### one month of support remains
-### 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.
-### if this bug remains open on: _____ (date of EOL) it will automatically be closed as WONTFIX
-### standard wording will be maintained on at the Bugzappers/BugzillaBoilerPlate ('''TODO: CREATE''') page
-=== One Day Before Release Date ===
-# Confirm that release day is for sure with release engineering.
-# Enable new version in Bugzilla
-# Request execution of ''rawhide-mover-script''
-=== Day of Release ===
-# Run ''eol-warning'' script
-# 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:
-## one month of support remains
-## please attempt to reproduce on most recent version of Fedora released which is: ____
-## if this bug remains open on: _____ (date of EOL) it will automatically be closed as WONTFIX
-# Run a quick query for '''all''' bugs that are !CLOSED (any state except CLOSED) for all release which have reached End of Life (EOL).
-## 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
-## Change status of bug to CLOSED.
-## standard wording will be maintained on at the Bugzappers/BugzillaBoilerPlate ('''TODO: CREATE''') page
-=== One Month after GA Release ===
-# Confirm EOL date with: '''FIXME'''
-# Run ''eol-closer'' script
-# Update this page with correct maintained and EOL Fedora versions
-# Update Bugzappers/BugzillaBoilerPlate ('''TODO: CREATE''') page with correct maintained and EOL Fedora versions
-=== Ongoing ===
-# Monitor '''all''' bugs that are !CLOSED (any state except CLOSED) for all release which are no longer maintained have reached End of Life (EOL).
-# 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 [[BugZappers/BugStatusWorkFlow|  bug life cycle]]  for more information and policies.
-== Bugzilla Script Lexicon ==
-# ''rawhide-mover'' mass moves all bugs currently open against the ''rawhide'' version to the latest released Fedora version
-# ''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
-# ''eol-closer'' closes '''all''' bugs for release becoming EOL

Search

BugZappers/HouseKeeping: Difference between revisions