Bugs/Workflow

What links here (4) →

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

FAQ

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

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. 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 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:

• 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 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:

• 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.

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.

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:

• write a comment about this. Request more information from user;
• send bug back to triage by ensuring its component is "Enter Bugs Here."

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.