Bugzilla Procedures

B0. The bug tracker is Bugzilla on sourceware.org. New users do not have the editbugs group access which means that while they can create bugs they cannot edit any aspects of the bug once created. This is done to avoid spammers modifying existing bugs. If you need the ability to edit bugs please request it on libc-alpha@sourceware.org or on IRC freenode at #glibc, the bugzilla admins and senior members of the community can grant this access once they know you're not a spammer.

B1. Open separate bugs for libc and ports, and preferably separate bugs for different ports, rather than one bug with both libc and ports patches, as different people will be dealing with different areas and a maintainer should be able to close a bug once they've dealt with the parts in their area. Similarly, if in doubt about whether a problem you observe has the same underlying cause as an existing bug, file a new bug for it rather than adding to the existing bug; closing duplicate bugs is easier than tracking the "partly-fixed" state of a bug that has over time changed what issues it covers.

B2. When committing a fix for a bug (whether libc or ports), remember to include the [BZ #N] notation in the ChangeLog entry, and to add the bug to the list in NEWS of bugs fixed in the next release. This applies for anything with a Bugzilla entry, including feature requests or cleanups that are not strictly "bugs" in the code.

B3. Bugzilla is for concrete issues with a substantially objective way of assessing whether the issue is still present. Questions of policy should be raised first on libc-alpha, and the resulting consensus documented on the wiki. (If the agreed policy implies some code in glibc is buggy, concrete bugs pointing to the policy may then be filed for fixing specific code.) For open-ended cleanup projects (where there isn't a clear and objective way to tell if the cleanup is complete), wiki pages rather than Bugzilla bugs are the appropriate way of tracking status. See discussion on libc-alpha.

Assignments and statuses

A1. Assigning a bug to unassigned@sourceware.org means it is not assigned to anyone.

A2. A bug being assigned to someone indicates that have an intention to work on a fix (or otherwise do some work on the bug) in the reasonably near future.

A3. If a bug is also ASSIGNED (rather than NEW), that indicates the person is actively working on a fix.

A4. If you simply think someone will be interested in a bug, CC rather than assigning them unless they have specifically asked to be assigned.

A5. A bug should be SUSPENDED if there is known to be something particularly hard about fixing a bug, not simply that a patch is needed. For example, if a bug cannot be fixed by libc maintainers on their own because various other components need to change as well, or because ABI implications make a fix hard. The person moving the bug into the SUSPENDED state should attempt to define the conditions for which the bug will come out of the SUSPENDED state e.g. SUSPENDED until GCC PR target/XXXX is fixed.

A6. Components should no longer have bugs default-assigned to particular individuals (that is, unassigned@sourceware.org should be the default assignment); rather, people should choose when to assign bugs to themselves when they have some specific intention with regard to a specific bug. Note that components can be configured to automatically CC someone when an issue is created against a given component. The following is the current list of people that will be CC'd when a bug is created against a component (listed here because this information is not visible to normal bugzilla users):


Default CC list


carlos@systemhalted.org, roland@gnu.org





roland@gnu.org, tschwinge@sourceware.org




















carlos@systemhalted.org, roland@gnu.org






A7. The default-assignments should be removed from existing open bugs. Rather than just removing them all blindly, it's better actually to look at a bug enough to decide you think it is a real issue still present in the current code, but that you're not going to fix it right now, and to decide if it's in the correct component, if possible, and to remove the assignment at the same time as making any comment you wish to make on the bug. (That is, removing default assignments is better done as part of triage than separately touching each bug for both purposes.)


Not generally used for glibc, see NEW


No-one is actively working on this bug (may or may not have been confirmed to be valid)


Someone is actively working on this bug (see A3 above)


Bug is particularly hard to fix (see A5 above)


Bug requires more information from submitter to make progress


Same as NEW, but bug was once closed


Bug is fixed, duplicate, not a bug or otherwise does not need to be open


Not generally used for glibc, see RESOLVED


Not generally used for glibc, see RESOLVED

Severities and priorities

S1. New features bugzilla entries should have the severity marked enhancement.

S2. Priorities are not generally used (i.e. they are left at the default).


K1. The keyword of an issue represents information about that issue.

K2. Each release branch should have a keyword named glibc_X.Y with a description that says Bug needed on stable glibc X.Y branch.. If the issue is tagged with a glibc_X.Y keyword then it defines the already released release branch that requires the fix.

K3. If an issue is tagged with the keyword testsuite then the issue contains a test suitable for use with test-skeleton.c.


F1. Flags may have four values: undefined, accepted, denied, requested.

F2. The "review" flag may be added to an issue any number of times. The purpose of the flag is to request help to review the bug, set the flag to "?" (requested) and type in the email of the reviewer you think will help. This setting will generate an email to the reviewer and the ticket will show up in their "My Requests" section of bugzilla. If the reviewer reviews the bug they should set the review flag to "+" indicating that you completed the review for the requester. If the reviewer is unable to review the bug they will set their review request to "-". Setting the bug review flag to "+" or "-" removes it from the reviewers request queue.

F3. The security flag indicates whether a bug is security-relevant. Setting a security flag does not make a bug private, all Bugzilla bugs are public. For details about reporting security bugs, see the security process documentation. Newly filed bugs do not have this flag and need to be triaged. Once this happens, they receive either security+ (security-relevant) or security- (not security-relevant). Tricky cases may temporarily receive security?, requesting additional review. If in doubt, leave this flag unset.


M1. The milestone of a closed bug (if set) is the earliest mainline release that will have the fix (if the release hasn't been made yet) or already has the fix (if the release has been made). Open bugs, and bugs closed other than as FIXED, should not have milestones set. If reopening a bug (e.g. if a fix was reverted), remember to clear the milestone.

Bug triage

See Bug_Triage.

None: Bugzilla Procedures (last edited 2016-07-15 13:41:37 by CarlosODonell)