Bugzilla Procedures

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):

Component

Default CC list

admin

carlos@systemhalted.org, roland@gnu.org

build

carlos@systemhalted.org

dynamic-link

hurd

roland@gnu.org, tschwinge@sourceware.org

libc

drepper.fsp@gmail.com

linuxthreads

drow@false.org

localedata

libc-locales@sources.redhat.com

malloc

manual

roland@gnu.org

math

aj@suse.de

network

nis

kukuk@suse.de

nptl

drepper.fsp@gmail.com

nscd

drepper.fsp@gmail.com

ports

carlos@systemhalted.org, roland@gnu.org

regex

drepper.fsp@gmail.com

soft-fp

joseph@codesourcery.com

stdio

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.)

UNCONFIRMED

Not generally used for glibc, see NEW

NEW

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

ASSIGNED

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

SUSPENDED

Bug is particularly hard to fix (see A5 above)

WAITING

Bug requires more information from submitter to make progress

REOPENED

Same as NEW, but bug was once closed

RESOLVED

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

VERIFIED

Not generally used for glibc, see RESOLVED

CLOSED

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).

Keywords

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.

Flags

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.

Milestones

M1. The milestone of a closed bug (if set) is the earliest release on the earliest branch that will have the fix (if the release hasn't been made yet) or already has the fix (if the release has been made). The milestone of an open bug is the next release on the earliest branch for which the fix is wanted.

M2. Set a milestone on a bug if you think the fix for that bug is ready for a given future release branch and should go in it. Generally the developer working on the bug will set the target milestone as a reflection of when they think the fix will go into a release. Coordination should happen between the developer and the branch manager the same way backports are coordinated.

M3. Branch manager reviews bugs with the milestone set before branching and decides which fixes should go in before the branchpoint (and determines as necessary whether to delay branching or let the branch go without everything wanted).

M4. Branch manager reviews bugs with the milestone set before subsequent point releases from the branch. The additional requirement is that they also be fixed on trunk first.

Notes about the procedure

The information in this section may not be current; there is little experience with the procedures here.

Milestones: If there are persistent problems with getting things fixed or reviewed in particular areas and so branches need to be made without all the desired fixes, invite more people to become trunk maintainers to fix and review patches in those areas. By recording which fixes were postponed past a branch we can get an idea of what areas need more maintainers, and look at past contributors in those areas to find suitable maintainer candidates.

Bug triage

See Bug_Triage.

None: Bugzilla Procedures (last edited 2012-06-24 14:42:55 by JosephMyers)