This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Second GCC 4.7.0 Release Candidate available from

Richard Guenther schrieb:
On Fri, 16 Mar 2012, Georg-Johann Lay wrote:

Richard Guenther schrieb:

GCC 4.7.0 Release Candidate available from

A second release candidate for GCC 4.7.0 is available from

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.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]