Richard Guenther schrieb:
On Fri, 16 Mar 2012, Georg-Johann Lay wrote:
Richard Guenther schrieb:
GCC 4.7.0 Release Candidate available from gcc.gnu.org
A second release candidate for GCC 4.7.0 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314
and shortly its mirrors. It has been generated from SVN revision 185376.
I have so far bootstrapped and tested the release candidate on
x86_64-linux. Please test it and report any issues to bugzilla.
Some days ago I learned that even if there are solutions to reported bugs,
these solutions is already upstream to trunk and approved to be backported to
4.7.1, these bugfixes are prohibited for the 4.7.0 release.
Can someone explain this "fix as few as possible bugs" rule to me?
I don't want to question that precedure, I just want to understand it.
If the reason is "not destabilize the release": What is the advantage of
having exact the same destabilization at a later point, namely for the 4.7.1
release in this specific case?
The points are as follows
1) we want to make a release at some point
2) we want to give people a chance to test the release beforehand,
thus we do a release candidate - main testing focus is that
weird targets get built, to rule out show-stoppers
3) if we apply changes to a release candidate 2) is invalidated so
we'd need another release candidate - see point 1)
4) for 4.7.1 there will be a release candidate as well, thus 2)
is re-validated
so the issue is simply that when we have created a RC we don't want
_any_ changes. Ideally. Otherwise doing a release candidate is
pointless and we could just release without doing release candidates.
Richard.
Ok, so the goal is that the releast is exactly the same as the (last)
release candidate.
I was just confused by the "please report bugs" which gives rise to the
(incorrect) assumption that the goal is to actually fix these bugs --
only if this is possible in a timely manner, of course, and won't delay
the release.
Thanks for explanation.
Johann
