Policies/Bug policy
From Mandriva Community Wiki
This document sets out the process for handling bug reports for Mandriva Linux. Please note that it covers only the main line Mandriva Linux distribution (including the Free, One, Discovery, Powerpack and Powerpack+ editions): it does not cover the Corporate product line (Multi Network Firewall, Corporate Server, Corporate Desktop). It is the aim of this document to make clear the responsibilities of all parties concerned (reporters, Bug Squad members and maintainers), and to cover all possible contingencies so it is always clear what action should be taken by whom to resolve any bug.
Contents |
[edit] Definition
A bug is defined as a case in which a component of a Mandriva Linux distribution (or other product covered by Bugzilla, such as a Mandriva web site) fails to fulfill its intended function.
[edit] Process
Bugs may be reported on Mandriva Linux by any user of the distribution. We aim to handle all bugs filed on Mandriva Linux. This does not necessarily mean that all bugs will be resolved in the manner considered best by the reporter; although we strive for this outcome wherever possible we recognize that it may sometimes not be possible. We will attempt wherever possible to handle invalid or misdirected bugs correctly and to resolve valid bugs.
This means that legitimate issues in supported packages must be fixed where possible. Where issues cannot be fixed, a full explanation of the circumstances is required. Either of these outcomes constitutes resolution. Where issues are duplicate, invalid, outside the scope of a bug resolution system or impossible to reproduce, they must be marked as RESOLVED with the appropriate status and a full explanation by either the package maintainer or a member of the Bug Squad. These outcomes also constitute resolution. No other outcomes may be held to constitute resolution.
[edit] Reporting
Bugs are to be reported to Bugzilla. The appropriate distribution and product must be selected by the reporter. A bug report should consist of a full description of the problem and, where appropriate, full details of the steps needed to reproduce the problem. All relevant information on the environment required to reproduce the problem - specific items of hardware, specific software packages, or specific configuration settings - must also be included. Suggested fixes, including patches, are welcomed but not required.
[edit] Voting
Anyone with a Bugzilla account may vote for a bug. This is a way of registering interest in a bug and desire for it to be fixed. Votes should be viewed as a factor (along with severity and priority ratings) for maintainers to use in prioritizing their bug resolution workload, and as a tool for monitoring.
Most hated (ie. voted for) bugs
Most wanted (ie. voted for) features
[edit] Triage
All bugs shall initially be the responsibility of the triage team. The triage team has two main responsibilities. Firstly, the triage team must decide whether an issue requires action on the part of the package maintainer or not.
[edit] Issues not requiring action by the package maintainer
The following cases do not require action by the package maintainer. Where an issue does not require action by the package maintainer, it is the responsibility of the triage team to resolve it.
- The bug is a duplicate of an existing report. This means that the same problem has already been reported on the same product in the same release. Reports of the same problem in different releases are not to be considered duplicates. Triage team members should set duplicate bugs to the RESOLVED DUPLICATE status. This constitutes resolution of the issue.
- The issue does not constitute a bug as defined above. This would be the case, for instance, where a bug report is filed which requests the creation of an additional feature in a piece of software not maintained by the Mandriva development team, or where a bug is filed as a result of an error on the part of the user. Triage team members should set issues which do not meet the definition of a 'bug' to the RESOLVED INVALID or RESOLVED WONTFIX status, except in the case of legitimate enhancement requests, which are covered in a separate section below. This constitutes resolution of the issue.
- The issue is not a duplicate and meets the definition of a bug, but would be better handled further up the development chain. Some issues cannot sensibly be resolved at the level of distribution packaging. Such issues include, for example, fundamental bugs in the code of an application. In this case, triage team members will request that the reporter report the bug to the appropriate level of the development chain via the most highly recommended method of reporting bugs for the project in question (for instance, ask them to report the bug to the GNOME Bugzilla, if it is a bug that would be better handled by the GNOME development team). Once this is done, triage team members or the reporter should set the Mandriva bug report to the RESOLVED REPORTEDUPSTREAM status, with a direct link to the upstream report. In the case of bugs filed on Cooker, this constitutes resolution of the issue, on the assumption that once the issue is fixed upstream, the updated version will be integrated into Mandriva Linux in reasonably short order. In the case of bugs filed on stable releases, this constitutes only temporary resolution of the issue, as new versions are not integrated into stable releases as a matter of course. Once the issue has been fixed upstream, the triage team or the initial reporter may re-open the bug, and it will then be re-evaluated in terms of whether it is practical to merge the upstream fix into an update for the Mandriva release.
[edit] Issues requiring action by the package maintainer
Issues which do not fall into the above categories - that is, issues which meet the definition of a bug, which have not been previously reported, which can be reproduced, and which can sensibly be resolved at the level of distribution packaging - are valid issues which require action on the part of the package maintainer. In these cases, the responsibility of the triage team is to ensure that all relevant information as laid out in the Reporting section above is received from the reporter, to set the priority and severity fields appropriately, and then to set the bug's status to ASSIGNED and ensure it is assigned to the appropriate maintainer. Triage team members should on no account assign bug reports to maintainers without first ensuring all the necessary information has been received.
Where all necessary information on a bug is contained in the initial report, the bug can simply be set to ASSIGNED and assigned immediately to the appropriate maintainer. At this point, the bug becomes the responsibility of the maintainer.
Where all necessary information is not contained in the initial report, triage team members should add the NEEDINFO keyword and append a comment informing the bug reporter precisely what additional information is required and either explaining, or linking to an explanation of, the steps necessary to produce this information. Until such action is taken, the bug is the responsibility of the triage team. Once such action is taken, the bug is the responsibility of the reporter until such time as they provide the additional information required. If such information is not received within a reasonable timeframe, or the reporter responds with a statement that they are unable to provide the information required, the issue becomes one that does not require action by the package maintainer and should be handled by the triage team accordingly.
The triage team must also set the priority and severity fields appropriately for each bug. Maintainers will use these fields to prioritize their workload, so their accuracy is vital. The priority field reflects how urgently the bug needs to be fixed; that is, it depends on how important the bug is in the context of the distribution as a whole. The severity field reflects how serious the bug is within the context of the package. So a critical bug in a package that is rarely used may be critical severity but low priority, and a minor but highly visible bug in a commonly used package may be minor severity but release_critical priority.
The release_critical priority is only relevant to bugs filed on Cooker or beta releases, and should only be used for issues which are sufficiently critical that it would severely impair the overall quality of a release if it were made available without the issue being resolved. The high priority should be used for issues which are sufficiently critical that resolving them should take priority over resolving other issues, but which do not meet the criteria for release_critical. The low priority should be used for bugs which are sufficiently trivial and/or limited in impact that resolving other issues should take precedence. The normal priority should be used for all other issues.
The critical severity should be used for bugs which render a package essentially unusable (for instance, crashes which would affect the majority of uses of a package, or total inability to install or run the package). The major severity should be used for issues which render a significant feature of the package unusable, or which render the package generally unstable. The minor severity should be used for issues which have only a limited impact on the usability of a package or which will only affect a small minority of users or use cases, and the trivial severity should be used for issues which have almost no material impact on the usability of a package. The normal severity should be used for all other issues.
Once the triage team has finished triaging a bug, they must add the Triaged keyword to the bug.
[edit] Maintainer resolution
Where an issue requires action on the part of the package maintainer and all the appropriate information has been provided by the reporter with the help of the triage team, it becomes the package maintainer's responsibility to resolve the issue. Maintainers may mark a bug as RESOLVED FIXED once they have identified a fix and committed it to SVN, but for stable releases, their responsibility does not end here. For supported packages, they should also ensure an official update is released, according to the Post-release support policy. It is desirable that a link be posted in the original bug report to the update request bug report (where the two are different), to enable users to follow the status of the update. For unsupported packages, it is desirable that the maintainer release an updated package directly to the appropriate repository.
The range of possible actions required to resolve bugs is, of course, beyond the scope of this document. Once the fixed package is available in the appropriate repository, it is the maintainer's responsibility to set the bug to the RESOLVED FIXED status.
[edit] Maintainers' ability to short-circuit triage process
There is one case where the above process may not be followed. It is acceptable for a package maintainer to short-circuit the triage process. If a bug has not yet been fully triaged but the maintainer of the affected package is confident that they are able to resolve the issue, they may take ownership of the bug. At this point, the maintainer has accepted responsibility for fixing the issue as reported, or for obtaining further information from the reporter. The bug is no longer the responsibility of the triage team, despite the fact that the triage process has not yet been fully completed. The maintainer may not then assign the bug back to the triage team.
[edit] VERIFIED and CLOSED
The states VERIFIED and CLOSED are not considered to be useful to our bug handling process and therefore there is no need for anyone to use these states on the Mandriva Bugzilla. When the maintainer considers an issue fixed it will be marked RESOLVED FIXED. If the reporter or the bug squad wishes to verify the closure, they can do so: if they confirm the bug is fixed, simply leave it as RESOLVED FIXED; if they find it is not fixed, they can re-open the bug.
[edit] Enhancement requests
A special case in the Mandriva bug tracking process are enhancement requests. Valid enhancement requests include requests for additional features in software that is written or maintained by Mandriva developers, and suggestions for enhancements in the actual packaging of software that is not written or maintained by Mandriva developers. Requests for additional features in software that is not written or maintained by Mandriva developers do not count as valid enhancement requests, and are covered under 'issues not requiring action by the package maintainer' above.
The triage team's responsibility in the case of enhancement requests is limited to ensuring that a full and comprehensible explanation of the feature request is provided by the reporter, and the severity field is correctly set to the enhancement value. At this point, the triage team should set the bug to the ASSIGNED status and assign it to the appropriate maintainer.
The maintainer is not obliged to accept any enhancement request. These do not constitute 'bugs' under the definition above and consequently it is not our policy that they will be resolved in all cases. The maintainer may choose whether or not to accept the request. If the maintainer chooses to accept the request, they should add a comment to this effect, and once the request is implemented in a package available through the appropriate repository, they should set the bug's status to the RESOLVED FIXED status. If the maintainer chooses not to accept the request, they should add a comment explaining their decision, and set the bug's status to the RESOLVED WONTFIX status. Either of these outcomes constitutes resolution of the issue.
