Skip to content

start:

Policies: Regressions

There are three categories of regression issues we're interested in:

  1. Functionality which is different from the same functionality in a previous version, but the difference is intentional, since the respective feature has been overworked, and specified differently than before.
  2. Functionality which is different from the same functionality in a previous version, and should be fixed. However, the issue is considered too minor to be a stopper for the next (micro) release.
  3. Functionality which is different from the same functionality in a previous version, and is serious enough to be a stopper for the next (micro) release.

Categorization of a regression issue into one of the three categories above happens as follows:

  1. After adding a justification (i.e. saying that the change is not considered a regression, but an implementation of a new/changed concept), the issue is handled as usual. No particular keyword is to be set. Any already existent regression keyword is to be revoked.
    In case that the changed functionality/behaviour is controversial, this should be discussed in the project (corresponding to the Issue Tracker Component), and may be brought to the project lead to come to a decision. If neccesary, the issue could be escalated to the project leads list. If you cannot escalate to the project leads list yourself, contact the Community Contributor Representative at the Community Council or the QA project.
    Alternatively and additionally, feel free to get support from other people, expressed for instance by votes on the issue
  2. The keyword "regression" is added to the issue (if not already present), together with a comment stating that the issue is not considered a blocker for the next release. The target is set to the next train release (e.g. "OOo 2.x") or "OOo later", depending on the judgement of the issue's severity. After that, the issue is handled as usual. In particular, depending on user feedback (e.g. votes), it might be decided to fix the issue in the next release.
  3. The keyword "release_blocker" is added to the issue, the target is set to the next minor release.

Resources: