Community Consensus

The GNU C Library is part of the GNU Project, and key developers have agreed to be responsible for the project direction (GNU package maintainers), and for adhering to GNU policy, those people are listed here.

The GNU C Library project uses a consensus-based community-driven development model.

Consensus: General agreement, characterized by the absence of sustained opposition to substantial issues by an important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments. Consensus need not imply unanimity. Although it is necessary for developer work to progress speedily, sufficient time is required for the discussion, negotiation and resolution of significant technical disagreements. Developers need to ensure discipline with respect to release schedules in order to avoid long review times. Similarly, to avoid re-discussion, developers have the responsibility of ensuring that their contribution takes into account all interests concerned, and that this standpoint is made clear at an early stage of the work rather than, for example, in a final patch or commit. (Language based loosely on the ISO definition).

1. How do I build consensus?

You build consensus in 5 very difficult steps:

The first step is to define success. Defining when you stop is important because continuing a technical discussion takes time and effort, and without a success criteria it has no end. Examples of success criteria include:

Do not start a discussion if you don't have a well written success criteria.

Identifying, resolving and summarizing are the next key parts of reaching consensus. There is no easy way to describe what should be done at each step, but it should be noted that recording participant positions and summarizing are key aspects of moving the technical discussion forward. The conversation should move forward, avoiding discussion of previous points, and should be focused on the next technical problem to discuss.

Ultimately the health of the project is the responsibility of the project stewards (official GNU maintainers for the project), and these people should be counted upon to assist in all aspects of consensus building.

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

2. Trivial Bug-Fix Changes

3. Machine Changes

4. WIP: Kernel syscalls wrappers

On a system with a traditional Unix-style kernel (i.e. we don’t look at Hurd when assessing this) we consider a syscall wrapper to be a function whose primary (preferably sole) purpose it is to provide a minimal C-callable interface to a kernel function that implements substantial portion of the semantics. The syscall wrapper may shuffle its arguments around, it may translate between the glibc ABI and some lower-level ABI, and it may not actually perform a system-call trap (e.g. clock_gettime), but it couldn't do what it does without invoking kernel code, and it doesn’t do any nontrivial work itself.

Traditionally it was the C library’s responsibility to provide minimally mediated C-callable access to all of the functionality of the kernel. At some point in the past the GNU C Library deviated from adding Linux-specific C-callable syscall wrappers on portability (e.g. futex) and/or backward compatibility grounds, but the project recognizes that this was a mistake. It is a mistake because it leads to a profusion of raw syscall wrappers in userspace, and these wrappers are often hard to write, hard to maintain, and glibc has all the infrastructure to handle them already. Adding these C-callable syscall wrappers to the system C library is the right course of action.

It should be noted that syscall wrappers that are OS-specific are subject to weaker compatibility guarantees than those functions which are standards conforming and completely implemented in glibc. When kernel syscalls are deprecated the best that userspace libraries can do is to continue to provide compatiblity symbols to the syscall wrappers for existing applications, but remove them for new static links (normal symbol deprecation process).

The following are the general guidelines for providing syscall wrappers:

5. Backports to release branches

This follow a different procedure, as described in Release policy documentation.

6. Locales

7. Other Changes

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

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.

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

10. Standards we use

C11 (internally, not exposed via headers):

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