This is the mail archive of the gcc@gcc.gnu.org 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 gcc.gnu.org


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.


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