Tentative high-level plans for 7.10.1

[Mikolaj Konarski]

> Our intent has always been that that the latest version on each branch is solid.  There have been one or two occasions when we have knowingly abandoned a dodgy release branch entirely, but not many.

Perhaps we could do the opposite. Announce beforehand that
a release branch X is going to be LTS (of Very Stable Release;
roughly 1 in 4 branches?) and so very few major new features
will be included in the release X+1 (there is just not enough
time for both, as Austin explained).
Then, on the GHC maintainers' side, put off accepting any
"I rewrote the compiler" commits into HEAD for long time.
On the community side, focus on bug fixes and non-disruptive,
incremental improvements. Avoid API changes, whatever that means.
Update release X many times, until very stable.

A more radical proposal would be to do the above, but announce
that X+! is going to be Very Stable Release and accept no major
new features into HEAD at all and even revert any minor new
features just before X+1 release, if non-trivial bugs in them are discovered.
Then release X can be abandoned quickly, knowing that X+! will most
probably resolve any problems in X, without introducing new ones.

In either case, the main point is the announcement and so the
focus of the community on bug-fixing and keeping HEAD close
to the named releases, to make bug-fixing and back- and forward-
porting easy.