Differences between revisions 7 and 8
Revision 7 as of 2008-04-17 19:13:25
Size: 4070
Comment:
Revision 8 as of 2012-02-19 17:13:19
Size: 3854
Editor: JosephMyers
Comment: Update and refer to separate descriptions of field semantics.
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 1. Identify duplicate bugs reports. Close duplicate reports as ''dupe''. Duplicates will show up on the [[http://sources.redhat.com/bugzilla/duplicates.cgi | GLIBC duplicate bugs]] page.  1. Identify duplicate bugs reports. Close duplicate reports as ''dupe''. Duplicates will show up on the [[http://sourceware.org/bugzilla/duplicates.cgi?product=glibc | GLIBC duplicate bugs]] page.
Line 12: Line 12:
 1. Set bug fields in accordance with [[bugzilla/procedures]].
Line 17: Line 18:
 1. Review old bugs in the same way from time to time.
Line 19: Line 21:
Further reading of {{{Roland McGrath's}}} comments regarding GLIBC bug triage [[http://sources.redhat.com/ml/libc-alpha/2005-10/msg00057.html | can be found here]]. Further reading of {{{Roland McGrath's}}} comments regarding GLIBC bug triage [[http://sourceware.org/ml/libc-alpha/2005-10/msg00057.html | can be found here]].
Line 24: Line 26:
 1. The bugzilla bug entry 'owner' field is an indication of the triage participant who is ''looking'' at the entry. If you're comfortable addressing the problem please assign yourself as the owner.  1. The bugzilla bug entry 'owner' field is an indication of the triage participant who is ''looking'' at the entry. If you're comfortable addressing the problem please assign yourself as the owner.  Please remember to unassign yourself if no longer working on a bug.
Line 26: Line 28:
 1. If you have questions on the process please contact <rsa at us dot ibm dot com>.  1. If you have questions on the process please contact libc-alpha@sourceware.org.
Line 29: Line 31:
== Guidelines for Bugzilla Severity and Priority ==
Bugzilla severity and priority guidelines:
== Guidelines for Bugzilla Fields ==
Line 32: Line 33:
=== Guidelines for Bugs ===
{{{#!wiki blue/solid
 * Every once in a while Ulrich will make a statement about what severity and priority is allowed for a particular type of bugs. We need to find and document those guidelines.
}}}
See [[bugzilla/procedures]] for what settings of various fields in bugs mean.
Line 38: Line 36:
New feature patches should have bugzilla entries created for them. This is done so that patches don't get lost and so the release manager is able to find all patches when it comes time to spin a release.
{{{#!wiki blue/solid
 * New features bugzilla entries should have the '''severity''' marked '''enhancement'''. Don't mess with the priority, i.e. leave it the default. Setting the priority to '''critical''' is a guaranteed way to get your bugzilla ignored.
 * Once a bugzilla entry is created a mailing list post to libc-alpha should be made directing the developers to look at the bugzilla.
}}}
New feature patches that don't get reviewed reasonably quickly should have bugzilla entries created for them; the same applies to other unreviewed patches that do not add new features. This is done so that patches don't get lost and so the release manager is able to find all patches when it comes time to spin a release.
Line 47: Line 41:
Before you file, take a look at the [[http://sources.redhat.com/bugzilla/duplicates.cgi | GLIBC duplicate bugs]] page to see if you're filing something that's already been identified. Also do a query in bugzilla before you file. Before you file, take a look at the [[http://sourceware.org/bugzilla/duplicates.cgi?product=glibc | GLIBC duplicate bugs]] page to see if you're filing something that's already been identified. Also do a query in bugzilla before you file.
Line 50: Line 44:
 1. Do not report build errors in bugzilla! Take it to #glibc on freenode or to the libc-help mailing list. If you've identified an actual problem with a Makefile you can bring that to libc-alpha directly.  1. Do not report build errors in bugzilla! Take it to #glibc on freenode or to the libc-help mailing list. If you've identified an actual problem with a Makefile you can bring that to libc-alpha directly.  ([[http://sourceware.org/ml/libc-alpha/2012-02/msg00385.html|Under discussion]].)
Line 55: Line 49:
The [[http://sources.redhat.com/bugzilla/ | Sourceware Bugzilla]] hosts GLIBC bugs under the '''glibc''' product. The [[http://sourceware.org/bugzilla/ | Sourceware Bugzilla]] hosts GLIBC bugs under the '''glibc''' product.

GLIBC Bugzilla Bug Triage

We're looking for volunteers to help with the GLIBC Bugzilla bug triage initiative. The following is the list of a triage participant's duties:

  1. Deal with new bug reports in a timely manner.
  2. Identify duplicate bugs reports. Close duplicate reports as dupe. Duplicates will show up on the GLIBC duplicate bugs page.

  3. Verify bug validity, which involves the following:
    • Verify the validity of the test-case (identify user error).
    • Verify the behavior against the existing documentation (info page and man page).
    • Verify the bug premise against applicable standards (i.e. C99, POSIX, ieee754, ieee754r, ieee854).
    • Ask for clarification of standards and documentation from developers.
  4. Narrow the breadth of the bug's scope if applicable.

  5. Set bug fields in accordance with bugzilla/procedures.

  6. Implement a minimal test-case from a user submitted test-case or create one if a test-case is lacking.
  7. Create a test-case that can be injected into the GLIBC test-skeleton.c framework.
  8. Pester developers via posting to libc-alpha.
  9. Once fixes are delivered verify that problem is fixed.
  10. Prepare fixes to man pages or info pages as necessary.
  11. Review old bugs in the same way from time to time.

Further reading of Roland McGrath's comments regarding GLIBC bug triage can be found here.

Participation Steps

  1. Don't be intimidated by the process. We appreciate contribution and the process can be refined as we go along.
  2. The bugzilla bug entry 'owner' field is an indication of the triage participant who is looking at the entry. If you're comfortable addressing the problem please assign yourself as the owner. Please remember to unassign yourself if no longer working on a bug.

  3. In the course of your bugzilla triage work you may identify two separate bugs. If you find the need to open a new bug entry follow the guidelines below.
  4. If you have questions on the process please contact libc-alpha@sourceware.org.

Guidelines for Bugzilla Fields

See bugzilla/procedures for what settings of various fields in bugs mean.

Guidelines for New Features

New feature patches that don't get reviewed reasonably quickly should have bugzilla entries created for them; the same applies to other unreviewed patches that do not add new features. This is done so that patches don't get lost and so the release manager is able to find all patches when it comes time to spin a release.

Submitting a Bug Report

If you would like to submit a bug report against GLIBC please read the GNU Guidelines for filing a GLIBC bug.

Before you file, take a look at the GLIBC duplicate bugs page to see if you're filing something that's already been identified. Also do a query in bugzilla before you file.

  1. Do not report build errors in bugzilla! Take it to #glibc on freenode or to the libc-help mailing list. If you've identified an actual problem with a Makefile you can bring that to libc-alpha directly. (Under discussion.)

  2. No man pages are part of glibc, DO NOT REPORT MAN PAGE BUGS HERE! There is a separate GLIBC man page project.

The Sourceware Bugzilla hosts GLIBC bugs under the glibc product.

None: Bug_Triage (last edited 2016-11-26 04:44:16 by CarlosODonell)