Glibc

The GNU C Library (glibc) in Fedora

Current Change Request

Use glibc 2.25 for Fedora 26: https://fedoraproject.org/wiki/Changes/GLIBC225

Usage of Fedora Rawhide

The Fedora Rawhide builds of the core libraries provided by glibc (C, threading, math, etc) are a rolling release of upstream glibc git master. The Fedora glibc maintainers feel they meet the goals of Rawhide as outlined (https://fedoraproject.org/wiki/Releases/Rawhide) and that all the releases are usable and at the same time represent the latest incremental improvements from upstream.

With a project of glibc's complexity there is a series of feedback loops that are important for both the upstream project and the downstream distributions that use glibc. The downstream distributions carry out important integration work that provides valuable feedback to the upstream project. The downstream distributions provide operational hours of testing for components in live environments which is otherwise impossible for upstream to carry out. Upstream in turn provides a platform for cross-distribution sharing of work and integration.

Upstream glibc has begun using downstream distributions to test out parallel and concurrency (P&C) changes in threading code; code that can't otherwise be tested without millions of hours of testing. Such code is reviewed, tested on as many machines as possible (Fedora glibc team tests on x86_64, i686, ppc64, ppc64le, s390, s390x, aarch64, arm), but it's final inclusion is dependent on an acknowledgement by the downstream distributions that it has operational integrity. To answer that request Red Hat and SUSE do the following: they integrate the patch into their rolling releases, SUSE into Factory/Tumbleweed and Red Hat into Rawhide. After a number of months of integration the patch is approved and it is checked in upstream for use by all the distributions. It could be said that upstream glibc is being too conservative here, and could checkin the patch, and just let everyone test the changes, but the reality is that only the mature and well-staffed distributions and hardware vendors (Intel, and IBM) are capable of triaging the eventual corner case problems with P&C changes. Therefore, commensurate with our community involvement and maturity, we assist upstream, with the hardware vendors involved at all levels of the work. This process produces a very high quality upstream glibc that can be used by a wider assortment of smaller distributions that don't have the ability to triage P&C issues. Smaller distributions are still welcome to participate with SUSE and Red Hat in similar work, picking up patches from glibc's patchwork to validate as needed.

The point to clarify here is that Rawhide is being used by the Fedora glibc team as a means to facilitate upstream inclusion of features important to the Fedora glibc team. This is slightly different than the Fedora developer perceived intent of Rawhide which is to serve as integration for upstream changes which are already approved.

The Fedora glibc team asked FESCo for clarification on this issue and if glibc's usage was an acceptable usage of Fedora Rawhide: https://pagure.io/fesco/issue/1638

The consensus appears to be that it is acceptable to create a feedback cycle between Fedora Rawhide and upstream where Rawhide may temporarily serve to help upstream. The key importance is in building a positive feedback loop between Rawhide and upstream that results in a higher quality upstream and thus a higher quality Rawhide. In addition, conservatism in what changes go into Rawhide that are not upstream is very important, since destabilizing changes have a detrimental effect on Rawhide and would not meet the usability criteria set out for Rawhide.