Release note bloat is getting out of hand - Mailing list pgsql-hackers

From Tom Lane
Subject Release note bloat is getting out of hand
Date
Msg-id 14276.1422850235@sss.pgh.pa.us
Whole thread Raw
Responses Re: Release note bloat is getting out of hand  (David G Johnston <david.g.johnston@gmail.com>)
Re: Release note bloat is getting out of hand  (Robert Haas <robertmhaas@gmail.com>)
Re: Release note bloat is getting out of hand  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
I noticed that the release notes now constitute 25% of our SGML
documentation, by line count at least:

[postgres@sss1 sgml]$ wc *.sgml ref/*.sgml | tail -1 336338  1116259 11124003 total
[postgres@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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: WIP: dynahash replacement for buffer table
Next
From: Amit Langote
Date:
Subject: A minor comment typo in parse_utilcmd.c