Re: Release Note Changes

On Nov 30, 2007 11:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > 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.
>
> Define "complete".
>
> > 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.
>
> So in other words, you don't *really* want "complete".

i think he means a list meant for end users which mentions all features and
bug fixes done for that release. Your argument of go read the CVS logs is
valid, but there are just too many for someone to go through to get the
complete picture. i mean people may end up reading 1000 + logs in a worst
case scenario to find out if a bug they are interested in is fixed , and the
someone who compiled the release notes didn't think it was important enough
to make it to the notes. Going through a 5K release notes document would be
half that time, granted that over time thier ability to read through logs
quicker will improve, but thats a learning curve they have to be willing to
go trough, and not everyone will be interested to do that

if i would have to find a word to describe what we need, i would say we need
something *compendious* i.e. what is at once full in scope and brief and
concise in treatment

it is however work that someone will have to do, but it can be managed as
such that it is a by-product of the process, instead of a 'one time in the
end' job.

>
>
> This discussion is all about finding a suitable balance between length
> and detail. Simplistic pronouncements don't help us strike that
> balance.
>
> FWIW, I tend to agree with the folks who think Bruce trimmed too much
> this time. But the release notes are, and always have been, intended to
> boil the CVS history down to something useful by eliminating irrelevant
> detail. For the vast majority of people, the details that are being
> mentioned here are indeed irrelevant. There will be some for whom they
> are not. But depending on the question, almost any detail might not be
> irrelevant, and at that point you have to be prepared to go check the
> archives.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

--
Usama Munir Dar http://linkedin.com/in/usamadar
Consultant Architect
Cell:+92 321 5020666
Skype: usamadar