Differences between revisions 6 and 7
Revision 6 as of 2012-04-05 15:05:58
Size: 3413
Comment:
Revision 7 as of 2012-04-05 15:33:12
Size: 4740
Editor: JosephMyers
Comment: List more cases of obvious changes.
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
The following is a list of items which have community consensus. The following is a nonexhaustive list of items which have community consensus.
Line 9: Line 9:
 * Anyone can commit a locale related change where a bugzilla issue exists, government sources are cited, common uses are cited, and if there is an original author for the locale, that original author ACKs the change. No developer review required. Post the the patch and ChangeLog to libc-alpha with a short message and then push the commit.  * Anyone can commit a locale related change where a bugzilla issue exists, government sources are cited, common uses are cited, and if there is an original author for the locale, that original author ACKs the change. No developer review required. Post the patch and ChangeLog to libc-alpha with a short message and then push the commit.
Line 12: Line 12:

 * Anyone can commit a change [[Regeneration|regenerating]] a file someone previously failed to regenerate, with the same version of the relevant tool such as autoconf. Only a mention of the commit is needed on libc-alpha, not the diffs of the regeneration.

 * Anyone can commit a change fixing obvious coding standards problems in a recently committed patch. Post the patch and ChangeLog to libc-alpha with a short message and then push the commit.

 * Anyone can commit a change adding a bug number to ChangeLog, NEWS or both; there is no need to post such a patch.

 * Anyone can commit a change adding missing #include directives where it is clear what the right header is for functionality used in a source file. Post the patch and ChangeLog to libc-alpha with a short message and then push the commit.

 * Anyone can commit a change adding LOCPATH settings for a testcase using locales. Post the patch and ChangeLog to libc-alpha with a short message and then push the commit.

 * Anyone can commit a change fixing code typos in a commit (e.g. from last-minute untested changes) that break the build or testing, where it is clear what the right fix is. Post the patch and ChangeLog to libc-alpha with a short message and then push the commit.
Line 16: Line 28:
== Subsystem Changes ==
 * There are no well identified subsystem maintainers. Seek the consensus of a minimum of two other senior developers before checking in your changes. If you get a scary feeling around the time you are about to push the commit, stop, and go ask for more review.
== Other Changes ==
 * There are no well identified subsystem maintainers for subsystems other than architecture-specific code. Seek the consensus of a minimum of two other senior developers before checking in your changes. If you get a scary feeling around the time you are about to push the commit, stop, and go ask for more review.

Community Consensus

The GNU C Library project is a consensus-based community-driven project.

The following is a nonexhaustive list of items which have community consensus.

1. Trivial Bug-Fix Changes

  • Anyone can commit a trivial patch to fix a spelling or grammatical error in a comment or manual. No developer review required. Post the patch and ChangeLog to libc-alpha/libc-ports with a short message and then push the commit.

  • Anyone can commit a locale related change where a bugzilla issue exists, government sources are cited, common uses are cited, and if there is an original author for the locale, that original author ACKs the change. No developer review required. Post the patch and ChangeLog to libc-alpha with a short message and then push the commit.

  • Anyone can commit an update to the libc.pot translation file given that the new libc.pot file came from the upstream translation project. No developer review required. Post the patch and ChangeLog to libc-alpha with a short message and then push the commit.

  • Anyone can commit a change regenerating a file someone previously failed to regenerate, with the same version of the relevant tool such as autoconf. Only a mention of the commit is needed on libc-alpha, not the diffs of the regeneration.

  • Anyone can commit a change fixing obvious coding standards problems in a recently committed patch. Post the patch and ChangeLog to libc-alpha with a short message and then push the commit.

  • Anyone can commit a change adding a bug number to ChangeLog, NEWS or both; there is no need to post such a patch.

  • Anyone can commit a change adding missing #include directives where it is clear what the right header is for functionality used in a source file. Post the patch and ChangeLog to libc-alpha with a short message and then push the commit.

  • Anyone can commit a change adding LOCPATH settings for a testcase using locales. Post the patch and ChangeLog to libc-alpha with a short message and then push the commit.

  • Anyone can commit a change fixing code typos in a commit (e.g. from last-minute untested changes) that break the build or testing, where it is clear what the right fix is. Post the patch and ChangeLog to libc-alpha with a short message and then push the commit.

2. Machine Changes

  • If you are a maintainer for a machine you are the expert and in a position of leadership. You should post your patches to libc-alpha/libc-ports for general review, but you may immediately commit your patches without the need for review. The community trusts your leadership and experience. If you are unsure about a change seek help and ask specific machine maintainers to review your patches for logical errors.

3. Other Changes

  • There are no well identified subsystem maintainers for subsystems other than architecture-specific code. Seek the consensus of a minimum of two other senior developers before checking in your changes. If you get a scary feeling around the time you are about to push the commit, stop, and go ask for more review.

4. Bad Changes

The source tree should always build and the testsuite should not regress without a clear reason posted to libc-alpha. If the build always works, and the testsuite is in a known good state, then the source is ready for any developers to commit changes. There is never any confusion about who or what patch regressed the testsuite, and bugs can be bisected because the source is always in a buildable state (or as close as possible).

  • Commits that break the build are immediately reverted.
  • Commits that regress the testsuite are immediately reverted.

Note that the libm tests (test-float, test-double, test-ldoubl, test-ifloat, test-idouble, test-ildoubl) test also the accuracy of routines and any new test might fail until the ulp files libm-test-ulps for that architecture is updated (see math/README.libm-tests). Note that unduly large ulps should not get added, these point to problems. So, for these routines, it's expected that the architecture files gets updated (after reviewing the change) as obvious.

5. Best Practice for Larger Changes

For doing larger changes, especially if those involve several architectures that the main author cannot test, the following work flow should be done:

  1. Create a branch and push it to the public glibc git repository as a personal branch.
  2. Test it on at least one architecture.
  3. Ask on the libc-alpha mailing list for review and testing by other parties. Give architecture maintainers enough time for this (an explicit deadline with 5 days should be ok)
  4. Merge the branch after getting reviews, additional tests - and no test failures.

None: Consensus (last edited 2019-06-27 21:02:48 by DmitryLevin)