Date: Sun, 26 Oct 2003 13:55:22 +0900 (JST)
Message-Id: <20031026.135522.112626548.t-ishii@sra.co.jp>
To: pgman@candle.pha.pa.us
Cc: peter_e@gmx.net, neilc@samurai.com, chriskl@familyhealth.com.au,
	tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
Subject: Re: 7.4 compatibility question
From: Tatsuo Ishii <t-ishii@sra.co.jp>
In-Reply-To: <200310260440.h9Q4eKl14349@candle.pha.pa.us>
References: <20031025.094403.41628799.t-ishii@sra.co.jp>
	<200310260440.h9Q4eKl14349@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Tatsuo Ishii wrote:
> > > I've been pushing this agenda for a few releases now, but some people have
> > > been, er, boycotting it.  I think, too, that release notes *must* be
> > > written incrementally at the same time that the feature change is made.
> > > This is the only way we can get accurate and complete release notes, and
> > > the descriptions could even include some context, some motivations, etc.
> > > We have release cycles of 10 months, and there is no way we can make
> > > sensible release notes by gathering individual commit messages over that
> > > period of time.  Heck, ECPG has a full Informix compatibility mode and
> > > there is no mention of that anywhere, because there was no commit "Add
> > > Informix mode."
> > > 
> > > I suggest we just do it like the documentation:  If you don't document it,
> > > it doesn't exist.  If you don't write a line for the release notes, it
> > > doesn't exist either.
> > 
> > I tend to agree it. For every release I and my colleague have been
> > working on creating detailed release notes (of course in Japanese),
> > otherwise we cannot tell people what are changed, added or fixed since
> > there is little info in the official release note. This is painful
> > since we have to dig into the mail archives and cvs commit messages to
> > look for what each item of the official release note actually
> > means. These work take at least 2 to 3 weeks with several people
> > involved. The hardest part is what are fixed. The only useful
> > information seems to be the cvs commit messages, however typical
> > messages are something like "see recent discussions in the mail
> > archive for more details". This is not very helpful at least for
> > me. Once I proposed that we add a sequence number to each mail and the
> > commit messages point to the number. This way we could easily trace
> > what are the bug report and what are the actual intention for the
> > fix. For some reason noboy was interested in. Maybe this is due to
> > "coulture gap"... (In Japan giving a sequence number to each mail in
> > mailing lists is quite common).
> 
> OK, if Tatsuo and SRA are having problems, I have to address it.  I can
> supply a more detailed list to Tatsuo/SRA, or I can beef up the release
> notes to contain more information.  Seems some in the community would
> like to have this detail so I might as well do it and have it in the
> official docs.  One idea would be to add a section at the bottom of the
> release notes that goes into detail on changes listed in the release
> notes above --- that way, people can still skim the 300-line release
> notes, and if they want detailed information about the optimizer changes
> or subtle pg_dump fixes, that will be at the bottom.
> 
> How does that sound?  I can start on this for 7.4 next week.  It
> basically means going through the CVS logs again and pulling out
> additional details.

Sounds good. However this kind of information could become huge and I
am afraid it does not suite well in the official docs in the source
tree. I think putiing it in somewhere in a web site (maybe
http://developer.postgresql.org/?) might be more appropreate.
What do you think?
--
Tatsuo Ishii