PySide Error Management: Difference between revisions
No edit summary |
AutoSpider (talk | contribs) (Rename category "LanguageBindings::PySide" -> "PySide") |
||
| (6 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category:PySide]] | |||
This page describes the error management guidelines used by the PySide core dev team. | This page describes the error management guidelines used by the PySide core dev team. | ||
'''NB:''' You | '''NB:''' You don't need any of the information below to report PySide bugs! Just go to [https://bugreports.qt.io/browse/PYSIDE PySide Bugzilla], fill the form, and be done with it! | ||
There is a nominated Error Manager (EM), who | There is a nominated Error Manager (EM), who "owns" the bugs in Bugzilla. Maintaining and prioritizing the Bugzilla is ultimately his/her responsibility. He takes care that no bugs are left hanging without explanation. The current EM is Matti Airas <matti.p.airas@nokia.com>. | ||
When a new bug comes in, EM evaluates it. Bug reporters may set the severity (enhancement..blocker) to indicate how serious they think the bug is The priority (P5..P1, P1 being the most important) is set by the EM and is used to indicate prioritization within the core dev team. | When a new bug comes in, EM evaluates it. Bug reporters may set the severity (enhancement..blocker) to indicate how serious they think the bug is The priority (P5..P1, P1 being the most important) is set by the EM and is used to indicate prioritization within the core dev team. | ||
Any new bug is in | Any new bug is in UNCONFIRMED state. If the bug is clear enough, it is moved to NEW. If not, then EM asks for a clarification. Other alternative resolutions are RESOLVED INVALID or RESOLVED WORKSFORME. In all cases, EM comments on the resolution and prioritization to inform the submitter. | ||
The priorities are as follows: | The priorities are as follows: | ||
* P3..P5 for normal or low-priority bugs (and all bug reports considered to be features). These are to be pulled into the core dev | * P3..P5 for normal or low-priority bugs (and all bug reports considered to be features). These are to be pulled into the core dev team's internal backlog. | ||
* P2 for bugs that must be fixed within the core dev | * P2 for bugs that must be fixed within the core dev team's current sprint | ||
* P1 for true blocker bugs that override everything | * P1 for true blocker bugs that override everything | ||
EM has the responsibility and authority for bug prioritization for bugs handled by the core dev team. Bugs belonging to community members are not prioritized by the EM (although the community members are free to prioritize their own bugs themselves). | EM has the responsibility and authority for bug prioritization for bugs handled by the core dev team. Bugs belonging to community members are not prioritized by the EM (although the community members are free to prioritize their own bugs themselves). | ||
Once work on a bug starts, the bug is marked | Once work on a bug starts, the bug is marked ASSIGNED and the bug is assigned to the person fixing the bug. | ||
Once a fix is committed, the bug is RESOLVED FIXED. | |||
Once a new PySide (or PySide Mobility) version release is made, bug is CLOSED. | |||
Latest revision as of 03:30, 5 June 2016
This page describes the error management guidelines used by the PySide core dev team.
NB: You don't need any of the information below to report PySide bugs! Just go to PySide Bugzilla, fill the form, and be done with it!
There is a nominated Error Manager (EM), who "owns" the bugs in Bugzilla. Maintaining and prioritizing the Bugzilla is ultimately his/her responsibility. He takes care that no bugs are left hanging without explanation. The current EM is Matti Airas <matti.p.airas@nokia.com>.
When a new bug comes in, EM evaluates it. Bug reporters may set the severity (enhancement..blocker) to indicate how serious they think the bug is The priority (P5..P1, P1 being the most important) is set by the EM and is used to indicate prioritization within the core dev team.
Any new bug is in UNCONFIRMED state. If the bug is clear enough, it is moved to NEW. If not, then EM asks for a clarification. Other alternative resolutions are RESOLVED INVALID or RESOLVED WORKSFORME. In all cases, EM comments on the resolution and prioritization to inform the submitter.
The priorities are as follows:
- P3..P5 for normal or low-priority bugs (and all bug reports considered to be features). These are to be pulled into the core dev team's internal backlog.
- P2 for bugs that must be fixed within the core dev team's current sprint
- P1 for true blocker bugs that override everything
EM has the responsibility and authority for bug prioritization for bugs handled by the core dev team. Bugs belonging to community members are not prioritized by the EM (although the community members are free to prioritize their own bugs themselves).
Once work on a bug starts, the bug is marked ASSIGNED and the bug is assigned to the person fixing the bug.
Once a fix is committed, the bug is RESOLVED FIXED.
Once a new PySide (or PySide Mobility) version release is made, bug is CLOSED.