Re: A minor adjustment to the development plan

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    I suggest to extend this by

    + * No regressions caused by the changes on the branch are logged against
    +   the GCC bugtracking system or have been brought to the attention of
    +   the branch maintainer(s) in some other way.

    Rationale: a regression we know about is a regression we know about,
    whether it occurs in the testsuite or not, and per our development plan
    patches which cause known regressions are not acceptable.

My feeling is that there's a difference when a branch is merged in because of
the size of the work being merged.  Certainly we don't want a branch to
introduce a lot of problems, but branch merging only occurs at a stage in the
development cycle when we are willing to tolerate some instability.

My concern is that both the branch and the mainline will be moving targets
and it may not be feasible to have a single point in time when all known
regressions have been fixed.  Obviously, you don't want to merge if things
can't bootstrap or there are a large number of regressions, but it may be
better to "take the hit" and introduce a few regressions than to keep
delaying the merge until it's perfect: if the number of regressions is small
enough, it's going to be far easier to fix them in the merged mainline than
to do so in the branch, while trying to keep it up to date with development
in the mainline.