Revision 1 as of 2013-11-09 04:05:51
add sse42 strstr as release blocker
|Deletions are marked like this.||Additions are marked like this.|
|Line 38:||Line 38:|
| * Decision about how to handle issues with SSE42 strstr et al:
1. Current 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/2.19/master: main branch
- glibc-2.19: revision releases tagged out of release/2.19/master
These people are interested in contents and further revisions tagged on the branch:
The general policies for release branches apply to this branch. Do you think a certain bugfix should be included in this branch?
- Is the fix committed in master? It has to be, unless it's not applicable to master (e.g. code has been rewritten meantime).
- Do you have commit permissions? If so, go ahead if you think it's reasonably safe. break;
- 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;
- Add the glibc_X.Y keyword to the appropriate bug report.
- 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!).
What things do we want to accomplish this release?
2.1. Release blockers?
- Decision about how to handle issues with SSE42 strstr et al:
2.2. Desirable this release?
3. Known Issues
3.1. Testsuite Failures
Build system: UNAME -a, GCC?, Binutils?, Kernel ?
TRIMMED LIST OF FAILURES.
3.2. Build Failures
Describe build failures here and how to fix them.
3.3. Packaging Changes
Describe any distribution packing changes that may be required.