• Release
• X.Y

Release/X.Y

Planning

What things do we want to accomplish this release?

Release Information

The release branch of glibc-X.Y is maintained by USER (USER@EMAIL) and its current release is X.Y.N, tagged on DATE. There are no immediate plans for the next release.

Machine status:

• MACHINE1, builds, no testsuite failures.
• MACHINE2, builds, some testsuite failures (listed below).
• MACHINE3, fails to build.
• ...

The ref structure of this branch is:

• release/X.Y/master: main branch
• glibc-X.Y.N: revision releases tagged out of release/X.Y/master

These people are interested in contents and further revisions tagged on the branch:

• PERSON1
• PERSON2
• ...

The general policies for release branches apply to this branch. Do you think a certain bugfix should be included in this branch?

1. Is the fix committed in master? It has to be, unless it's not applicable to master (e.g. code has been rewritten meantime).
2. Do you have commit permissions? If so, go ahead if you think it's reasonably safe. break;
3. Can you handle Git yourself? Then you can clone the glibc repository, cherry-pick the appropriate fixes, push your branch out and send a pull request at libc-alpha. break;
4. Add the glibc_X.Y keyword to the appropriate bug report.
5. If there is no appropriate bug report, send a request for the fix to be included to libc-alpha.

A revision release is tagged either when some critical bug-fix appears, or after some period of real-world testing, usually mainly in some SUSE distribution branch (but other distributions are welcome to run latest release/X.Y/master as well, more so if they tell me about it!).

Known Issues

Testsuite Failures

Build system: UNAME -a, GCC?, Binutils?, Kernel ?

TRIMMED LIST OF FAILURES.

Build Failures

Describe build failures here and how to fix them.