PySide Error Management: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
(Rename category "LanguageBindings::PySide" -> "PySide")
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
=PySide Error Management=
 
 
[[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 don’t need any of the information below to report PySide bugs! Just go to [https://bugreports.qt.io/browse/PYSIDE PySide Bugzilla] ''[bugreports.qt.io]'', fill the form, and be done with it!
'''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 “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>.
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 <span class="caps">UNCONFIRMED</span> state. If the bug is clear enough, it is moved to <span class="caps">NEW</span>. If not, then EM asks for a clarification. Other alternative resolutions are <span class="caps">RESOLVED</span> <span class="caps">INVALID</span> or <span class="caps">RESOLVED</span> <span class="caps">WORKSFORME</span>. In all cases, EM comments on the resolution and prioritization to inform the submitter.
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 team’s internal backlog.
* 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
* 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 <span class="caps">ASSIGNED</span> and the bug is assigned to the person fixing the bug.
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 <span class="caps">RESOLVED</span> <span class="caps">FIXED</span>.
 
Once a new PySide (or PySide Mobility) version release is made, bug is <span class="caps">CLOSED</span>.
 
After any resolution, the submitter may <span class="caps">REOPEN</span> the bug if the issue didn’t get properly resolved.


===Categories:===
Once a fix is committed, the bug is RESOLVED FIXED.


* [[:Category:LanguageBindings|LanguageBindings]]
Once a new PySide (or PySide Mobility) version release is made, bug is CLOSED.
** [[:Category:LanguageBindings::PySide|PySide]]

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.