BugZappers/HouseKeeping
From FedoraProject
Contents |
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 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 and beta 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
FutureFeaturekeyword
- 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 (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
- 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
- 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
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
