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.