On Wed, 9 Jan 2019, Paul Koning wrote:

> 
> 
> > On Jan 9, 2019, at 3:42 AM, Tom de Vries <tdevr...@suse.de> wrote:
> > 
> > [ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ]
> > 
> > The current formulation for the description of Stage 4 here (
> > https://gcc.gnu.org/develop.html ) is:
> > ...
> > During this period, the only (non-documentation) changes that may be
> > made are changes that fix regressions.
> > 
> > Other changes may not be done during this period.
> > 
> > Note that the same constraints apply to release branches.
> > 
> > This period lasts until stage 1 opens for the next release.
> > ...
> > 
> > This updated formulation was proposed by Richi (with a request for
> > review of wording):
> > ...
> > During this period, the only (non-documentation) changes that may
> > be made are changes that fix regressions.
> > 
> > -Other changes may not be done during this period.
> > +Other important bugs like wrong-code, rejects-valid or build issues may
> > +be fixed as well.  All changes during this period should be done with
> > +extra care on not introducing new regressions - fixing bugs at all cost
> > +is not wanted.
> ...
> 
> Is there, or should there be, a distinction between primary and non-primary 
> platforms?  While platform bugs typically require fixes in platform-specific 
> code, I would think we would want to stay away from bugfixes in minor 
> platforms during stage 4.  The wording seems to say that I could fix 
> wrong-code bugs in pdp11 during stage 4; I have been assuming I should not do 
> that.  Is this something that should be explicitly stated?

I think it's somewhere stated that during Stage 3 non-primary/secondary 
targets as well as non-C/C++ languages have no restrictions.  Of course
while technically true breaking builds is still not wanted.

For Stage 4 things are somewhat different I think, not sure if it's 
anywhere spelled out.

Richard.

Reply via email to