This section contains information mostly intended for GCC contributors.
If you find a bug, but you are not fixing it (yet):
If you want to provide additional information about an existing bug report:
If you fix a bug:
Bugzilla offers a number of different fields. From a maintainer's perspective, these are the relevant ones and what their values mean:
The following two fields describe how serious a bug is from a user's perspective (Severity) and what Priority we assign to it in fixing it:
SeverityThis field describes the impact of a bug.
PriorityFor regressions this field describes the importance and order in which a bug should be fixed. Priorities are set by the release management team only. If you think a priority is wrong, set it to P3 and add a note. The available priorities are:
As a general rule of thumb, within each priority level, bugs that result in incorrect code (keyword wrong-code) are considered equally as important to fix as those that lead to rejecting valid code (rejects-valid) and as those that cause an ICE for valid code (ice-on-valid-code). Lower in importance, however, are accepts-invalid and ice-on-invalid bugs, and less important still are missed-optimization opportunities.
Regressions that only affect more recent releases are prioritized over those that also affect older releases. For example, prior to the release of GCC 7, a regression that was introduced in GCC 6 and that affects GCC 7 is considered more important to fix in GCC 7 than a regression that was introduced in GCC 5 (and is still present in GCC 6 and 7).
This is the person in charge of resolving the bug. Every time this field changes, the status changes to NEW to make it easy to see which new bugs have appeared on a person's list.
These are used to further classify the problem reports. Follow the link for a complete list of the keywords including descriptions.
Putting reports in components "C", "C++", and "optimization" in state "NEW" requires that there is a reduced, small testcase. This makes sure that all NEW reports are really analyzed and are ready to be handed off to the people actually fixing bugs.
Regressions should be explicitly marked as such. The summary line should read
[branches-to-fix regression] rest-of-summary
where branches-to-fix is the list of maintained branches (separated by slashes) that need fixing. The target milestone should be set to the next release of the newest active release branch that needs fixing (the rationale is that a patch will have to go to the newest release branch before any other release branch). The priority of a regression should initially be set to P3. The milestone and the priority can be changed by the release manager and his/her delegates.
If a patch fixing a PR has been submitted, a link to the message with the patch should be added to the PR, as well as the keyword "patch".
Meta-bugs (reports with the keyword "meta-bug") are used to group PRs that have a common denominator. Meta-bugs do not have testcases of their own, but provide links to regular PRs via Bugzilla's "depends on/blocks" mechanism instead: they depend on the regular PRs. Information concerning the majority of bugs blocking a meta-bug should be added to the meta-bug instead of each single PR.
Bugs with keyword "ice-on-invalid-code", where GCC emits a sensible error message before issuing an ICE (the ICE will be replaced by the message "confused by earlier errors, bailing out" in release versions) should get "minor" severity and the additional keyword "error-recovery".
Bugs in component "bootstrap" that refer to older releases or snapshots/CVS versions should be put into state "WAITING", asking the reporter whether she can still reproduce the problem and to report her findings in any case (whether positive or negative).
Bugs that are in state "WAITING" because they lack information that is necessary for reproducing the problem can be closed if no response was received for three months.
When closing a PR because it got fixed, please set the target milestone to the first release where it will be/has been fixed. Also adjust the target milestone when a fix is backported. Finally, please adjust the Known To Fail and Known To Work fields to record what was fixed.
Duplicate PRs should be marked as such. If you encounter a PR that is marked as "resolved fixed", but should be marked as a duplicate, please change the resolution. (You have to reopen the PR before you can resolve it as a duplicate.)
Copyright (C) Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.