[I apologize to those of you receiving duplicate copies of this mail. I thought so hard about copying people that I forgot to address to the list.]
Table of contents: 1. PRs 2. Schedule 3. Rationale If you're in the CC: list, there are possible action items for you below. (Recent feedback was to provide more frequent status reports and to nag more -- I'll do my best!) PRs === At this point, we're very, very close to meeting the (admittedly limited) goal for 4.2.0 of having no P1 regressions from 4.1.x. The remaining PRs are: 1. PR 26792: libstdc++ on Darwin uses functions not present in the system libgcc This PR has apparently been fixed on the mainline. If a Darwin maintainer (Dale, Mike, Geoff) would like to backport this to 4.2, that would be great. 2. PR 30222: crash on gcc.target/i386/vectorize1.c This PR is apparently due to only part of a mainline patch being applied to 4.2. It was so diagnosed in December 2006, but nobody has identified the missing part of the mainline patch. Andrew, as you've diagnosed the problem, would you please identify the solution? 3. PR 30567: Wrong code with -O3 due to aliasing problems Richard G. has analyzed this and proposed a patch. Richard, is this ready to go? If not, do you need help? 4. PR 31360: Missed optimization I don't generally mark missed optimization bugs as P1, but not hoisting loads of zero out of a 4-instruction loop is bad. Zdenek has fixed this on mainline. Andrew says that patch has a bug. So, what's the story here? Schedule ======== I'm not going to consider any of these issues blockers after Sunday, April 29. At that point, I plan to freeze the branch and build a release candidate. Then, about a week later, I plan to release 4.2.0. There has been more than enough time for people to test and fix bugs. Rationale ========= There are far too many constraints on releases to make everyone happy. All of the following objectives and suggestions have been made by intelligent, knowledgeable people: 1. Release early and often. 2. Take longer between releases so there's more time for major development. 3. Align releases with distributor schedules. 4. Take a feature-driven view: release when a pre-defined set of new features are available. 5. Take a time-driven view: release on a particular date, no matter what. 6. Take a quality-driven view: release when there are no severe bugs. I've gotten a little paralyzed with this release. I've wanted to take some combination of (4), (5), and (6), and I've made a hash of it. I'm going to cut my losses and 4.2.0 out the door. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713