Re: Release Note Changes

Greg,

> Frankly I think the release notes are already too long. People who judge a
> release by counting the number of items in the release notes are not worth
> appeasing. Including every individual lock removed or code path optimized
> will only obscure the important points on which people should be judging
> the relevance of the release to them. Things like smoothing checkpoint i/o
> which could be removing a show-stopper problem for them.

I disagree.  For people who want a quick summary of the major user-facing 
things changed we'll have multiple sources:  (a) the announcement, (b) the 
press features list, (c) the Feature-Version matrix.  The Release notes 
should have a *complete* list of changes.

Why?  Because we don't use a bug/feature tracker.  So a user trying to figure 
out "hey, was my issue XXX fixed so that I should upgrade?" has *no other 
source* than the Release notes to look at, except CVS history.  And if we 
start asking sysadmins and application vendors to read the CVS history, we're 
gonna simply push them towards other DBMSes which have this information more 
clearly.

If we want to shorten the release notes, then we should adopt an issue 
tracker.

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco