(Update with respect to https://fedoraproject.org/wiki/Milestone_Adjustment_Proposal) |
|||
(23 intermediate revisions by 6 users not shown) | |||
Line 1: | Line 1: | ||
{{autolang|base=yes}} | |||
= Fedora 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. | * 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 | * See the [[BugZappers/HouseKeeping/Releases | release tracker page]] which contains links to pages for each release where these procedures where run and recorded | ||
== Task Breakdown == | == 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. | 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. | ||
Line 15: | Line 20: | ||
== Versioning == | == Versioning == | ||
* Fedora tracks bugs solely | |||
* Fedora tracks bugs solely for numbered releases or [[Releases/Rawhide|Rawhide]] | |||
* Fedora does '''not''' create separate | * 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. | ** 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 Version == | == Rawhide Version == | ||
* ''Rawhide'' is a unique version number in that it refers to the | * ''Rawhide'' is a unique version number in that it refers to the release stream always under development. | ||
* At or around the | * At or around the Feature Freeze milestone, a new release is ''branched'' from ''rawhide.'' | ||
** For example, | * 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. | * 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. | ** 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. | ** 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 === | === Rawhide Bugs Excluded From Rebase === | ||
* Feature requests or ''Requests for Enhancement'' (RFEs) | * Feature requests or ''Requests for Enhancement'' (RFEs) | ||
Line 36: | Line 45: | ||
* Tracking bugs | * Tracking bugs | ||
== Tracker | == 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 [[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. | |||
== End of Life (EOL) == | == 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. | * Releases for which updates are no longer provided are considered to be ''unmaintained'' and thus ''End of Life'' or commonly referred to as ''EOL''. | ||
* See [[ | * 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 | 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.}} | {{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.}} | ||
== SOP Review & Approval Process == | == SOP Review & Approval Process == | ||
Line 66: | Line 68: | ||
* http://www.redhat.com/archives/fedora-test-list/2008-March/msg00834.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}} | {{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}} | ||
---- | ---- | ||
[[Category:BugTriage]] | [[Category:BugTriage]] | ||
[[Category:BugZappers_SOPs]] |
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.
- First Day of Development
- Four Weeks Before Release Date
- Two Weeks Before Release Date
- One Day Before Release Date
- One Month after GA Release
- Ongoing
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
- Feature requests or RFEs are designated by the
- 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.
SOP Review & Approval Process
- 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