Bugs/Workflow

What links here (4) →

This is a draft of Bugzilla Workflow. This is not an actual policy.

Scope

The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product, and to all components "Desktop Features." Other categories are free and encouraged to adopt this workflow, but this is not mandatory.

Filing a bug

All bugs must be filed to "Enter Bugs Here" component. This component accumulates all untriaged bugs. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.

Several categories of people may also enter the bugs to other components, thus skipping the triage:

• ROSA Tech Support First Level if the bugs have been triaged in the helpdesk
• maintainers and developers—against their own packges/subsystem. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.
• Testers—when testing ISO images.

If the component has been chosen incorrectly, and the bug still needs more information, the assignee should click the "Needs More Triage" button.

Bug Triage

Bug triage should start no later than five days since the bug was filed (ensured by #Whining).

By Bug Triage we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:

• at least one version affected by the bug (enter the latest one to the Version field, if several are affected);
• steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive);
• information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at Bugs/AskUser page (NOTE: based on Firstlevel workflow)
• the problematic package RPM name (there's a specific field that should be filed), its version and release.
• pay specific attention to whether the bug is a duplicate of another bug. See #Diplicates for policy for closing duplicates.
• assign the correct product and component. See #Bug Categories. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.

Finishing the Triage

When bug triage is over, the triager presses "Finish Triage" button. If the button is not available, then you forgot to change the component, which you should ave done; see above. The bug will be handled to developers (see #Initial Resolution).

Problems detected at Triage

A triage, however may reveal some problems with the report:

• The user realized that everything is OK; ensure that the status is RESOLVED INVALID;
• The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.
• The user doesn't respond to the questions necessary for the triage for as much as 3 months since the bug was filed. Close as RESOLVED INVALID (ensured by #Whining).

Initial Resolution

Initial resolution applies to new bugs in "Main Packages," "Contributed Packages," and "Package Requests." components. status means the bug has been triaged, and there is no evidence that it can't be reproduced. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.

The initial analysis can lead to several results:

• it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just to resolve bugs in them, see Repo_Policy#Meaning_of_.22Maintained_by_ROSA.22;
• if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:
  • our: we are the upstream, or we are to fix it anyway (default state)
  • unknown: The bug should be filed to upstream
  • known: upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)
  • wontfix: the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)

The upstream status has no effect on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix should not be closed, as we might want to make a workaround, or choose another upstream component for this purpose.

• The bug severity is determined by the criteria described in the Bugs/Severity policy.

Further steps

When the bug is confirmed, triaged, and its upstream status is unknown or our, the bug is handed to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.

Other Resolutions

Aside from getting triaged, and then fixed, bug may have a less lucky destiny.

Bug reproduction

Anybody may perform attempt to reproduce the bug. This is not a mandatory step for triage. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste.

When somebody reproduces the bug, they may leave a note about this. If the bug can't be reproduced, and more information from user is needed, you must:

• write a comment about this. Request more information from user;
• Click "Back to Triage" button. This sends bug back to triage.

If a bug can't be reproduced three months after this fact is detected, the bug may be closed with RESOLVED WORKSFORME status.

WONTFIX bugs

Sometimes—though 'very rarely—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.

In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution always originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.

Fixing and publishing bugs

When a maintainer/developer decides to fix a bug, he or she does the following:

• sets the status to IN_PROGRESS
• sets the bug assignee to self
• optionally, sets the target milestone to the release the fix should appear in.

After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per Submission Policy.

If the bug that should be in another Product/Component, change it, as per #Bug Categories.

Duplicates

At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with more advanced status to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).

Documentation

When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.

Bug Categories

Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):

ROSA Desktop/Main Packages

errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet

ROSA Desktop/Contributed Packages

errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases

ROSA Desktop/Package Requests

Requests to build new packages for specific software.

ROSA Desktop/Localization

localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon

ROSA Desktop/LXDE Edition

Bugs specific to LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.

ROSA Desktop/GNOME Edition

Bugs specific to GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.

Desktop Features/All

Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.

Technical Details

Mailing Lists

The default QA contact and assignee for new UNCONFIRMED bugs is triage@lists.rosalab.ru. Everybody who wants to participate in bug triaging should subscribe to this list.

The CONFIRMED bugs will have bugs@lists.rosalab.ru as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.

Whining

By "ensured by whining" we mean that unless the specified action is taken in the specified amount of time, Bugzilla will automatically send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.

For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.