From Fedora Project Wiki
m (1 revision(s))
 
(37 intermediate revisions by 9 users not shown)
Line 1: Line 1:
= Bugzilla Maintenance SOP =
{{autolang|base=yes}}


= 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.
* See the [[BugZappers/HouseKeeping/Releases | release tracker page]] which contains links to pages for each release where these procedures where run and recorded


== 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


{{ Template:message/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 ==
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.
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.


And if you think this is too aggressive you're welcome to keep your bugs alive by continually moving them to the latest version.
* [[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/DayBeforeRelease | One Day Before Release Date ]]
* [[BugZappers/HouseKeeping/MonthAfterRelease  |One Month after GA Release ]]
* [[BugZappers/HouseKeeping/OnGoing | Ongoing ]]


== Versioning ==


== Bugzilla Product Versioning ==
* Fedora tracks bugs solely for numbered releases or [[Releases/Rawhide|Rawhide]]
* 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 versions in Bugzilla for pre-release milestones (e.g. Alpha and Beta)  
* 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.
* Each release is added to Bugzilla at the point it is [[Releases/Branched|branched]] from Rawhide
* Changes to this policy require review and approval by FESCo.
* 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 release stream always 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 Feature Freeze milestone, a new release is ''branched'' from ''rawhide.'' 
* 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.
* The branched tree represents the new release of Fedora and a corresponding version number is added to Bugzilla
* Rebasing ''rawhide'' bugs each release cycle also provides information on how many bugs are filed during a given development cycle.
** Bugs for the branched release are tracked under the upcoming release number version.
** At ''branching'', bugs assigned to the ''rawhide'' version are rebased (changed) to the new release version as they are most closely associated with that version.
** For example, when Fedora 22 branches from rawhide, all open bugs for ''rawhide'' (with some exceptions) are changed to Fedora ''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 <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
* Tracking bugs


== Tracker Bugs ==
== 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
1. Beta
1. 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 bugs are single bugs used to keep track of several other related bugs.  Fedora  uses tracker bugs to keep track of bugs that need to be fixed during key milestones in the [[Fedora Release Life Cycle|development process]] ([[QA:SOP_blocker_bug_process|blocker bugs]]) and bugs for which fixes will be accepted through [[Milestone freezes|milestone freeze]] periods ([[QA:SOP_freeze_exception_bug_process|freeze exception bugs]]). QA is responsible for creating tracker bugs for each release. See [[BugZappers/HouseKeeping/Trackers| the tracker bugs page]] for a listing of the current tracker bugs and process around creating them.


* 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]
== End of Life (EOL) ==


{{ Template:message/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.
* 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 bugs for EOL releases are automatically closed on the EOL date after providing a warning in the bug comments, 30 days prior to EOL.
* See [[Fedora Release Life Cycle]] for more information about how long releases are maintained and list of releases with their current status.


{{Admon/note|Unmaintained releases|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.}}


== Currently Supported Versions ==
== SOP Review & Approval Process ==
* Fedora 9: EOL one month after GA of Fedora 11 (''roughly'' May 1, 2009)
* http://www.redhat.com/archives/fedora-devel-list/2008-March/msg00881.html
* Fedora 8: EOL one month after GA of Fedora 10 (''roughly'' November 30, 2008)
* http://www.redhat.com/archives/fedora-devel-list/2008-March/msg01199.html
* Fedora 7: EOL on 2008-06-13
* http://www.redhat.com/archives/fedora-devel-announce/2008-March/msg00005.html
* All other versions of Fedora are ''unmaintained'' and thus ''End Of Life'' (EOL).
* http://jstanley.fedorapeople.org/meetings/bugzapper0312.txt
 
* http://bpepple.fedorapeople.org/fesco/FESCo-2008-03-13.html
{{ Template:message/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.
* 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
== Release Processes ==
{{ Template:message/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.
}}
 
 
=== 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
1. 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.
1. Update text that refers to the latest Fedora version on these pages (coordinate wording with marketing):
a. https://bugzilla.redhat.com/
a. https://bugzilla.redhat.com/enter_bug.cgi
1. 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
a. '''DECIDE''': Should these bugs be put in special state or tagged in some way (e.g. keyword)?
a. include text explaining that:
i. one month of support remains
i. please attempt to reproduce on most recent version of Fedora released which is: '''FIXME'''
i. if you discover this bug is present in the most recent version please change the version to that release
i. 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
i. if this bug remains open on: '''FIXME''' it will automatically be ''CLOSED:WONTFIX''
1. 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:
a. change status to CLOSED WONTFIX
a. include text explaining that:
i. 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.
i. 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.
i. 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:
a. select all bugs !CLOSED (any status except CLOSED)
a. select all bugs open for the version becoming EOL
a. include text explaining that:
i. one month of support remains
i. 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.
i. if this bug remains open on: _____ (date of EOL) it will automatically be closed as WONTFIX
i. 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.
1. Enable new version in Bugzilla
1. Request execution of ''rawhide-mover-script''
 
=== Day of Release ===
1. Run ''eol-warning'' script
1. 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:
a. one month of support remains
a. please attempt to reproduce on most recent version of Fedora released which is: ____
a. if this bug remains open on: _____ (date of EOL) it will automatically be closed as WONTFIX
1. Run a quick query for '''all''' bugs that are !CLOSED (any state except CLOSED) for all release which have reached End of Life (EOL).
a. 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
a. Change status of bug to CLOSED.
a. standard wording will be maintained on at the Bugzappers/BugzillaBoilerPlate ('''TODO: CREATE''') page
 
=== One Month after GA Release ===
1. Confirm EOL date with: '''FIXME'''
1. Run ''eol-closer'' script
1. Update this page with correct maintained and EOL Fedora versions
1. Update Bugzappers/BugzillaBoilerPlate ('''TODO: CREATE''') page with correct maintained and EOL Fedora versions


=== Ongoing ===
{{Admon/note|Review and approval|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}}
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).
1. 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 ==
----
1. ''rawhide-mover'' mass moves all bugs currently open against the ''rawhide'' version to the latest released Fedora version
[[Category:BugTriage]]
1. ''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
[[Category:BugZappers_SOPs]]
1. ''eol-closer'' closes '''all''' bugs for release becoming EOL

Latest revision as of 00:02, 28 January 2015

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.
  • See the release tracker page which contains links to pages for each release where these procedures where run and recorded

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 for numbered releases or Rawhide
  • Fedora does not create separate versions in Bugzilla for pre-release milestones (e.g. Alpha and Beta)
    • Fedora tried this structure in the past, but it provided very little benefit and was difficult to maintain and use consistently.
  • Each release is added to Bugzilla at the point it is branched from Rawhide
  • Changes to this policy require review and approval by FESCo.

Rawhide Version

  • Rawhide is a unique version number in that it refers to the release stream always under development.
  • At or around the Feature Freeze milestone, a new release is branched from rawhide.
  • The branched tree represents the new release of Fedora and a corresponding version number is added to Bugzilla
    • Bugs for the branched release are tracked under the upcoming release number version.
    • At branching, bugs assigned to the rawhide version are rebased (changed) to the new release version as they are most closely associated with that version.
    • For example, when Fedora 22 branches from rawhide, all open bugs for rawhide (with some exceptions) are changed to Fedora 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
  • Tracking bugs

Tracker Bugs

Tracker bugs are single bugs used to keep track of several other related bugs. Fedora uses tracker bugs to keep track of bugs that need to be fixed during key milestones in the development process (blocker bugs) and bugs for which fixes will be accepted through milestone freeze periods (freeze exception bugs). QA is responsible for creating tracker bugs for each release. See the tracker bugs page for a listing of the current tracker bugs and process around creating them.

End of Life (EOL)

  • 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 bugs for EOL releases are automatically closed on the EOL date after providing a warning in the bug comments, 30 days prior to EOL.
  • See Fedora Release Life Cycle for more information about how long releases are maintained and list of releases with their current status.
Unmaintained releases
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

Review and approval
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
Retrieved from "https://fedoraproject.org/w/index.php?title=BugZappers/HouseKeeping&oldid=402005"