Glibc stable release process (Glibc 2.26.1)

Hello All,

As suggested by Siddhesh Poyarekar in BZ-22146 [0], I'd like to continue the
discussion about tagging a 2.26.1 release.

Glibc 2.26 introduced some regressions (notably BZ-21930 and BZ-22146) on major
architectures (x86 and x86_64) that are already fixed in the stable branch.
Without them, we can't compile C++ any code using mathematical functions (ex:
std::fpclassify() when libstdc++ is compiled with -Os).

Siddhesh Poyarekar said that is no plan for a new release since most
distributions prefer to backport patches. But for downstream users like build
tools (Buildroot, crosstool-ng, Yocto...) that use the release archives, it
means that a lot of patches need to be backported (42 at the time of writing).

However, the point is not about choosing what commit to cherry-pick.
From the downstream perspective, a commit on the maintenance branch is always
worth it. If it were not needed, it would not have been committed to the
maintenance branch in the first place.

Gabriel F. T. Gomes suggested the use of a git clone from a given hash instead
but, as explained by Yann E. Morin, using "2.26.1" is much more descriptive than
using a random hash from the stable branch.

A new dot-release is a strong indication that the most critical fixes have made
their way to the maintenance branch, and that it has been officially sanctioned
by upstream (you! ;-)), which is a very important status for downstreams.


We do understand that getting a new release out can be quite some work, and we
do acknowledge the efforts that are made to provide those releases.

Yet, being able to refer to human-readable versions is very important.

Maybe a middle ground is that a tag is pushed to the repository, just to
identify a specific sha1 as "this is 2.26.1". This is relatively lightweight (a
signed tag) and gives downstream users that need it a clear identification of a
blessed version.


Thank you!

[0] https://sourceware.org/bugzilla/show_bug.cgi?id=22146

Best regards,
Romain Naour