Add release note introduction.

diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml
index ae5131ebec96ec993adb868d579cf90020a5fcf8..0129ae62bcc17089e4af6ae203f94f638c8fb888 100644 (file)
--- a/doc/src/sgml/release.sgml
+++ b/doc/src/sgml/release.sgml
@@ -35,6 +35,37 @@ do it for earlier branch release files.
 <appendix id="release">
  <title>Release Notes</title>
 
+ <sect1 id="release-introduction">
+  <title>Introduction</title>
+
+  <para>
+   The release notes contain the significant changes in each PostgreSQL
+   release, with major features and migration issues often listed at the
+   top.  The release notes do not contain changes that affect only a few
+   users or changes that are internal and therefore not user-visible.  For
+   example, the optimizer is improved in almost every release, but the
+   improvements are usually observed by users as simply faster queries.
+  </para>
+
+  <para>
+   A complete list of changes for each release can be obtained by
+   viewing the <link linkend="cvs">CVS</> logs for each release.  The <ulink
+   url="http://archives.postgresql.org/pgsql-committers/">committers email
+   list</ulink> contains all source code changes as well.   There is also
+   a <ulink url="http://developer.postgresql.org/cvsweb.cgi/pgsql/">web
+   interface</ulink> that shows changes to specific files.
+   <!-- we need a file containing the CVS logs for each release, and something
+   like the SVN web interface that groups commits but has branches -->
+  </para>
+
+  <para>
+   The name appearing next to each item represents the major developer for
+   that item.  Of course all changes involve community discussion and patch
+   review so each item is truly a community effort.
+  </para>
+
+ </sect1>
+
  <sect1 id="release-8-3">
   <title>Release 8.3</title>