Josh Berkus wrote:
> 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.
We do mention bug fixes in the release notes if they affect more than a
few users. For rare bugs the original bug submitter is told what
release will have the fix as part of the bug fxing discussion. If it
wasn't fixed right away and became a TODO item that item is removed as
part of the release. (I just did that for 8.3.)
It is true we don't have a tracker but I have not seen a major demand
for it, or at least not enough for someone to actually do the work
required to list _all_ fixes/changes in a release. The job isn't that
hard, maybe a few days work for someone experienced.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
