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
