Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.

PySide Error Management

From Qt Wiki
Revision as of 03:30, 5 June 2016 by AutoSpider (talk | contribs) (Rename category "LanguageBindings::PySide" -> "PySide")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search



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.