Bugs/Workflow
This is a draft of Bugzilla Workflow. This is not an actual policy.
Contents
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
By default, all bugs enter the Bugzilla in UNCONFIRMED status. 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 can enter the bugs as CONFIRMED:
- 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.
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.
- (optional) 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.
When bug triage is over, the triager sets the CONFIRMED status. This is enough to notify the developers that such bug is ready to be prioritized and fixed.
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
So the bug is marked as CONFIRMED. The CONFIRMED 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 resolve bugs in them;
- 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[1] (default state)
- unknown: The bug should be filed to upstream[2]
- 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.
Bug reproduction
The bug may be challenged by a developer or a tester or anybody to be reproduced. 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. Until the bug reproduction attempt was made, and gained no result, the bug stays in CONFIRMED state.
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.
Further steps
When the bug is unconfirmed, and its upstream status is unknown or our, the bug transfers 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.
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.
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.
