Release note bloat is getting out of hand

I noticed that the release notes now constitute 25% of our SGML
documentation, by line count at least:

[postgres(at)sss1 sgml]$ wc *.sgml ref/*.sgml | tail -1
336338 1116259 11124003 total
[postgres(at)sss1 sgml]$ wc release-*.sgml | tail -1
85139 267417 2516545 total

Another way to measure it is that Appendix E (release notes) is
up to 270 subsections:
http://www.postgresql.org/docs/devel/static/release.html

That's starting to seem a bit excessive. And it's only going to get
worse, because each set of minor releases adds hundreds of not thousands
of lines here; for example the current set of release note additions
weighs in at

doc/src/sgml/release-9.0.sgml | 641 +++++++++++++++
doc/src/sgml/release-9.1.sgml | 725 +++++++++++++++++
doc/src/sgml/release-9.2.sgml | 832 +++++++++++++++++++
doc/src/sgml/release-9.3.sgml | 1746 ++++++++++++++++++++++++++++++++++++++++
doc/src/sgml/release-9.4.sgml | 674 ++++++++++++++++

I think it's time we changed the policy of including all release notes
back to the beginning in Appendix E. I seem to recall we debated this
once before, and decided that we liked having all that project history
visible. But Release 6.0 is old enough to vote as of last week, so really
we no longer need to prove anything about project stability/longevity.

I propose that we go over to a policy of keeping in HEAD only release
notes for actively maintained branches, and that each back branch should
retain notes only for branches that were actively maintained when it split
off from HEAD. This would keep about five years worth of history in
Appendix E, which should be a roughly stable amount of text.

(Note I'm *not* proposing applying this policy in time for this week's
releases. There's plenty of time to think about it.)

regards, tom lane