glibc 2.3.6

[Roland McGrath <roland at redhat dot com>]

Hi folks.  I'm getting ready to release 2.3.6 real soon now.  Really this time.
It's been months and months since the first few times I said it might be
along any day now.  But this time I mean it.

If you have a bugzilla report open that I recently put into WAITING state
(hi Hurd folks!), please do the testing or whatever it is I said in my comment.
I would like to get those nits worked out and the verified changes over to
the 2.3 branch in the next several days.

I have merged what should be the minimal working subset of the changes for
compiling with GCC 4 (thanks to the Andreases for helping extract those).
I have not and will not attempt to merge all the changes that just suppress
new compiler warnings.  The branch will get just what is necessary to make
it compile with the newer GCCs and not have functional regressions.  I have
done a little testing on a few configurations and will do some more.  There
are probably kinks left for some platforms on GCC 4, and I may have just
broken things.  Please test the current branch contents on the
configurations you can, using both old and new compilers.  If changes to
the branch are needed for your platforms, please try to keep them as close
as possible to exact specific changes that went onto the trunk at some point.

Here is the list of resolved issues so far (vs 2.3.5):

   38, 253, 549, 622, 653, 721, 851, 877, 915, 934, 955, 961, 1016,
   1037, 1076, 1079, 1080, 1081, 1082, 1083, 1084, 1085, 1086, 1087,
   1088, 1090, 1091, 1092, 1093, 1094, 1095, 1096, 1097, 1098, 1099,
   1100, 1101, 1102, 1103, 1104, 1105, 1106, 1107, 1108, 1109, 1110,
   1111, 1112, 1113, 1137, 1138, 1250, 1251, 1252, 1350, 1358, 1394,
   1438

I think this covers everything that's on the branch now.  If there are other
reports you think merit consideration for 2.3.6, please answer these questions:

1. Is it filed in bugzilla?  If not, file it first.
   (If it's already resolved on the trunk but didn't ever have a BZ#,
   then be sure to cite the relevant ChangeLog entries in the one you file.)
2. Is it already fixed on the trunk?  If not, resolve that and start again.
3. Do you have a working backport patch for the 2.3 branch?  If not, make one.
4. Has the change you're proposing been in a 2.3-based build given
   production or production-like testing, substantial QA, or public testing
   of your binaries?  If not, it's not ready to be in the stable release.


There are numerous worthwhile and safe-looking fixes on the trunk that
probably belong in a 2.3.x release before too long, that are not merged.
Following is a list of potential candidates culled from the ChangeLog.  But
I think these all can't make it past question #4 yet.  My current thinking
is that 2.3.6 should go out with approximately what's on the branch now,
and more fixes can go into the branch as they get more testing in 2.3
production builds, with 2.3.7 in perhaps a month or two if that testing
seems thorough by then.

If you think some of these items are too risky or otherwise inappropriate
for the stable branch, please let me know.

1061
1318
1331
1051
1010
1346
1035
934
395
704
545
714
524
627
644
713
838
1078
1158
1230
1384
1466
1405
1459
1460
1468
1102
968
1228


Thanks,
Roland