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

Contents

FAQ

Info1.png
This section is informational .
It is to help to understand key concepts to the persons involved, and to remind them of steps they are to perform as a part of the subsequent policy.

What is that triage thing?

Triage is basically asking user questions and "baking" bug so it looks yummy-yummy enough for developers to eat it. See more in #Bug Triage.

How to find bugs that should be triaged?

  1. Check the list of bugs awaiting triage.
  2. Subscribe to the triage-desktop mailing list

Your job, as a member of the Triage Team is to keep this list empty.

How to notify everyone that the triage has been started?

Put a question mark in the need_info flag. Optionally, put the reporter's email to show that you're needing info from him or her. This means that you have asked the reporter a question, and are waiting for their answer.

I asked user a question, but why is the bug still in the list of bugs awaiting triage?

You forgot to put a question mark to the need_info flag.

How to send the bug to develoeprs?

Change the bug's component from "-Enter Bugs Here-" to the proper one. See #Bug Categories.

Will I receive the messages after the triage has been finished?

If you were personally involved in triage, then yes. You are automatically added to CC list, and unless you remove yourself, you'll receive messages. If you just received this via triage-desktop@ mailing list, then no.

I am a developer, what should I do to not participate in triage?

Don't do anything. In particular, do not subscribe to triage-desktop@ mailing list. Subscribing to bugs@ will make you receive messages about triaged bugs only.

How to send bug back to triage?

Change its component to "-Enter Bugs Here-".

Somebody filed the bug directly to Main Pakcages without triage, should I send the bug back?

First, check if the bug really needs triage. Maybe it was filed by a developer or tester of ROSA Desktop, who knows what information is necessary. Maybe it has already been triaged in helpdesk. If the bug really needs triage, change its component to "-Enter Bugs Here-".

How to triage private bugs?

They're triaged like all other bugs. However, the messages are sent to private-bugs@ mailing list rather than to the desktop-triage@. You will see them in the list of bugs awaiting triage, however, if you have enough permissions, with a lock sign nearby.


Policy

Info1.png
The rest of this document is a pending policy.
The Technical Committee agreed that we should start to work as follows, but the policy is subject to small changes in the near future.

Scope

The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product in ROSA Bugzilla. 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:

If the component has been chosen incorrectly, and the bug still needs more information, the assignee should reassign the component back to "Enter Bugs Here".

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:

Finishing the Triage

When bug triage is over, the triager sets the proper component, and bugzilla will change assignee and QA contact automatically. The bug will be handled to developers (see #Initial Resolution).

Problems detected at Triage

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

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:

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.

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.

Fixing and publishing bugs

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

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.

Other Resolutions

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

Reproducing Bugs and Failing to Do so

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:

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.

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/Enter Bugs Here
a central point of contact for new bugs. You should file your bugs here;
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 untriaged bugs is triage-desktop@lists.rosalab.ru. Everybody who wants to participate in bug triaging should subscribe to this list, see ROSA Mailing Lists.

The bugs in other components, where the triaged bugs reside, will have bugs@lists.rosalab.ru as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage-desktop@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.

References

  1. for instance, if it's a bug in our fixes to an upstream package
  2. we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by #Whining)