 |
Other languages Deutsch ; English ; Français ; |
Introduction
This article lays out the process for handling bug reports for Mageia. It is the aim of this document to make clear the responsibilities of all parties concerned (reporters, Bug Squad members and package maintainers), and to cover all possible contingencies so it is always clear what action should be taken by whom to resolve any bug.
Definition
A bug is defined as a case in which a component of a Mageia Linux distribution (or other Components covered by the Mageia Bugzilla), fails to fulfil its intended function(s).
Process
Bugs may be reported against Mageia by any user of the distribution. We aim to handle all bugs filed on Mageia. 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 sometimes may not be possible. We will attempt wherever possible to handle invalid or misdirected bugs correctly and to resolve any valid ones.
This means that legitimate issues in supported packages must be fixed wherever possible. Where issues cannot be fixed, a full explanation of the circumstances is required. Either of these outcomes constitutes resolution. Where issues are duplicates, 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.
Reporting
Bugs are to be reported in 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 always welcome but not required.
Triage
All bugs shall initially be the responsibility of the Bug Squad. While triaging, the Bug Squad has two main responsibilities. Firstly, the Bug Squad must decide whether an issue requires action on the part of the package maintainer or not.
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 Bug Squad 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. Bug Squad 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 requests the creation of an additional feature in a piece of software not maintained by the Mageia development team, or where a bug is filed as a result of an error on the part of the user. Bug Squad members should set issues that do not meet the definition of a 'bug' to either 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.
- [This paragraph could be in the next section, the bug being assigned to the appropriate packager or group. Bugsquad is not always qualified to judge whether a bug is UPSTREAM, whereas packagers might do this better].
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, Bug Squad 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, the upstream bug URL should be put in the bug URL header field. It should be left open, and the UPSTREAM keyword added to the Mageia bug. The Mageia bug should not be marked RESOLVED until a determination is made (either it is eventually FIXED or WONTFIX/OLD).
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 Bug Squad is to ensure that all relevant information (as laid out in the Reporting section above) has been supplied by the reporter, to set the Priority and Severity fields appropriately and ensure it is assigned to the appropriate maintainer.
Note: this can apply to bugs marked UPSTREAM.
Bug Squad 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 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, Bug Squad members should add the NEEDINFO keyword and append a comment informing the bug reporter about what additional information is required exactly 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 Bug Squad. 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 time frame, or the reporter responds with a statement that he is 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 Bug Squad accordingly.
The Bug Squad 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 of critical severity but low priority, and a minor but highly visible bug in a commonly used package may be of minor severity but release_blocker priority.
Priority Values
- The release_blocker priority is mostly relevant for bugs filed on stabilisation snapshots and release candidates (obviously no bug is release_blocker for an already released distribution), 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_blocker.
- 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.
Severity Values
- 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
- The enhancement severity should be used for improvements that are not bug fixes, and for package requests
- The normal severity should be used for all other issues.
Once the Bug Squad has finished triaging a bug, they may add the Triaged keyword to the bug.
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 Bug Squad), 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.
Maintainers' ability to circumvent the triage process
There is one case where the above process may not be followed: It is acceptable for a package maintainer to circumvent the triage process.
If a bug has not yet been fully triaged but the maintainer of the affected package is confident that he is 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, and/or for obtaining further information from the reporter. The bug is no longer the responsibility of the Bug Squad, despite the fact that the triage process has not yet been fully completed. The maintainer may not then assign the bug back to the Bug Squad.
VERIFIED and CLOSED
The state VERIFIED is not considered to be useful to our bug handling process and therefore there is no need for anyone to use these states on the Mageia 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.
Enhancement requests
A special case in the Mageia bug tracking process are enhancement requests. Valid enhancement requests include requests for additional features in software that is written or maintained by Mageia developers, and suggestions for enhancements in the actual packaging of software that is not written or maintained by Mageia developers. Requests for additional features in software that is not written or maintained by Mageia developers do not count as valid enhancement requests, and are covered under 'issues not requiring action by the package maintainer' above.
The Bug Squad'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 Bug Squad should assign the bug report 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.
