Second GCC 4.7.0 Release Candidate available from gcc.gnu.org

[Georg-Johann Lay]

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