Revision as of 16:33, 24 May 2008

Bugzilla Extreme Make Over Fedora 9

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

Fedora has a proliferation of open bugs, so much so, that we are getting to the point (or may well have reached it) that it is becoming unmanageable. It does not seem logical to believe that we can continue on as we are and not do long term damage to the Fedora project.

The time to act is now!

By not addressing this arms race of bugs we put a brighter Fedora future in jeopardy: 1. We alienate community members that report bugs, but do not see a timely response, if ever. 1. As fewer people report bugs, the quality of Fedora releases has a higher chance of declining 1. We discourage community bug triagers from joining a situation where the results of their work cannot be seen because bug activity is lost in the ocean of other bugs. 1. We distract new bug triagers who want to focus time on the easiest bugs (versions which are EOL) which provide very little value to current work

To create a bug process that scales and is manageable there needs to be an inherent process that guides bugs to closure over time. It is well established that Fedora is not capable of maintaining more than two releases at a time and therefore it does not make sense to track bugs for releases where packages are no longer maintained and updates will never be released.

This proposal seeks resolve bugs from the distant past by giving them one last chance (see processes below). A second proposal which will become part of Fedora's Bug Triage SOP (standard operating procedures) is at HouseKeeping which will also guide bugs to closure.

We need to start ASAP so there is enough time to let the proposed process below run its course prior to 2008-04-29 (GA for Fedora 9).

Goal

1. Request community feedback on mailing lists and IRC 1. Have FESCo review and approve this proposal 1. Completely execute this proposal in stages by GA of Fedora 9

Open Bugs for EOL Versions

Fedora Core for versions 1 through 6

Overall EOL strategy

Change status of all open bugs to NEEDINFO and close all open bugs after waiting 30 days

Implementation (eol)

1. START: now() 1. Script executed by RHT Engineering Operations which queries bugs according to following criteria and takes the following actions: a. Version of Fedora (1 to 6) a. Status !CLOSED (any bug not in a closed state) a. Ascertain if bug is a blocker or tracker bug 1. Set bugs meeting criteria to NEEDINFO 1. Identify bugs is being used as a tracker or blocker bug a. add special keyword of Tracking to identify this bug for proper handling in the future a. Change version to rawhide? a. use keyword to exclude from subsequent searches 1. Add a friendly comment addressing the following: a. apologize for untimely response to this issue a. explain present situation and go-forward plan a. request that, if at all possible, they reproduce the bug against Fedora 8 or a Fedora 9 test release (version rawhide) a. if bug exists in current version, change version of bug to current version: 8 or rawhide a. if bug owner wishes (for whatever reason) for the bug to remain open, the version must be changed to Fedora 8 and status of ASSIGNED. a. if this bug remains open against EOL version it will be auto-closed as WONTFIX 30 days from now i. regardless of current open state (NEW, ASSIGNED, NEEDINFO, MODIFIED, etc.) i. there will no additional warnings or waiting period 1. END: now() + 30 days

Open Bugs for rawhide

Fedora bugs for version rawhide
open rawhide bugs are harder to address because it is not readily apparent which released Fedora version they are most closely tied to--the following sub-sections address this problem
In order to keep rawhide bugs on the path to closure they will be rebased at each Fedora GA date. This process is described here: HouseKeeping
For example all rawhide bugs at GA for Fedora 9 will rebase from version: rawhide ==> 9
Two releases + one month from the GA of Fedora 9, Fedora 9 will be EOL and all Fedora 9 bugs will be automatically closed as WONTFIX after being given the opportunity to reproduced against and moved to a current Fedora version

Overall strategy

separate very stale rawhide bugs from relevant rawhide bugs using the previous release schedule as a guide: http://fedoraproject.org/wiki/Releases/HistoricalSchedules
stratify bugs and process in buckets resulting in bugs that will be automatically closed OR manually triaged as part of the regular processes
sync up rawhide bugs with the currently supported release going forward and rebase the version to the GA version on or around the GA date.

Implementation

Script written and executed by RHT Engineering Operations which selects bugs according to specified criteria and takes the specified actions.

Stale Rawhide (stale)

1. START: now() 1. Select all bugs meeting the following criteria: a. Version = rawhide a. All states !CLOSED (Any status other than CLOSED) a. All bugs !component == "package review" a. All bugs !keyword == Tracking a. No comments or internal activity of any kind since GA of Fedora 7 (May 31, 2007): nine months of inactivity

Most likely these are bugs reported against releases that are EOL (FC6 or older)
admittedly this is a little aggressive, but risk is low; but we need to address as many of these as possible--a bug can always be reopened.

1. If the bug is being used as a tracker or blocker bug add special keyword of Tracking to identify this bug for proper handling in the future 1. Act on each bug meeting the specified criteria: a. Change bug status for all bugs meeting criteria to NEEDINFO a. Add whiteboard tag of bzcl34nup

this helps to clearly tag bugs targeted for this exercise--the date of last activity will no longer be an accurate field to trigger off of after posting comments requesting action.

a. Add a friendly comment addressing the following: i. apologize for untimely response to this issue i. explain present situation and go-forward plan i. request that, if at all possible, they reproduce the bug against Fedora 8 or a Fedora 9 test release (rawhide) i. if the bug exists in current version, change version of bug to current version (or leave as rawhide) and change status to NEW

NEW rawhide bugs will be picked up in subsequent step and manually triaged

i. if no action is taken this bug will be auto-closed as WONTFIX 30 days from now without any additional warnings or waiting period i. if bug is being used as a tracking bug add keyword of Tracking and change status to ASSIGNED 1. now() + 30 days a. Select all bugs meeting the following criteria: i. Version = rawhide i. whiteboard tag of bzcl34nup i. Status = NEEDINFO i. Not a tracker bug (does NOT have Tracking keyword set) a. auto-close bugs as WONTFIX a. Add a friendly comment explaining the following: i. following up to request posted 30 days ago i. if bug exists in a currently supported version feel free to reopen bug against that release

Possibly Relevant Rawhide (relevant)

The easiest way to get these bugs into the pipeline for eventual closeout or resolution is be to tie them to the Fedora 8 release

1. START and END: now() 1. Selection criteria a. rawhide version a. Opened AFTER May 31, 2007, but BEFORE November 1, 2007 a. Any status other than CLOSED a. Not a tracker bug (does NOT have Tracking keyword set) a. All bugs !component == "package review" 1. Action: a. Change version to Fedora 8 a. add a friendly note i. highlight version change i. explain reason for change i. include link to this proposal

Current Rawhide

Opened against rawhide version on or after November 1, 2007
Do nothing to these bugs--they will be addressed as part of good bugzilla hygiene
Once all of the above processes have run--take regular triage actions on these bugs
Triagers review all rawhide bugs in NEW or NEEDINFO

Comments, Concerns & Questions

John Poelstra

1. Suggestions from a few people to take snapshot/capture metrics on package and maintainer distribution among stale bugs before and after clean up

Action Plan & Timeline

see RunTime for the current status and results of executing this proposal. It also contains notes on things to think about and do differently as the process progresses.

Search

BugZappers/F9CleanUp: Difference between revisions