Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> I think I prefer the file-of-notes idea, but this is a possibility worth
>> suggesting.

> We can do whatever people want.  I was just afraid it would be too much
> work for people, and I am willing to continue doing it. Actually, if
> people want to help, looking over the final is 10x more valuable than
> having a separate file, at least for me.

Even if people do review the notes, who's to say they'll remember a
change they made months ago?  I think it's important for developers to
prepare at least a rough-draft entry for the release notes at the time
the change is made.  We can debate different ways to keep that info
available until the docs are prepared, but the real problem here is to
not rely on memory.

			regards, tom lane

Fri, 08 Feb 2002 16:03:39 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Maintaining the list of release changes 
On Fri, Feb 08, 2002 at 04:03:39PM -0500, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> I think I prefer the file-of-notes idea, but this is a possibility worth
> >> suggesting.
> 
> > We can do whatever people want.  I was just afraid it would be too much
> > work for people, and I am willing to continue doing it. Actually, if
> > people want to help, looking over the final is 10x more valuable than
> > having a separate file, at least for me.
> 
> Even if people do review the notes, who's to say they'll remember a
> change they made months ago?  I think it's important for developers to
> prepare at least a rough-draft entry for the release notes at the time
> the change is made.  We can debate different ways to keep that info
> available until the docs are prepared, but the real problem here is to
> not rely on memory.

The _really_ critical piece for making this cumulative file work: _every_
user visible change needs to go into it, at the time it's commited to CVS.
Be hardnosed, so external patches _must_ touch that file, or put it in
the commit log. The problem with the commit log is that it puts the onus
on the CVS commiter, not the patch maker.

I'm partial to a combo - a 'USER VISIBLE CHANGES: <yes|no>' line in CVS
commit logs (put it in the template, default to yes?) and every 'yes'
submit _must_ patch the cumulative release file.

Ross

Fri, 8 Feb 2002 16:13:46 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: Maintaining the list of release changes
"Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> I'm partial to a combo - a 'USER VISIBLE CHANGES: <yes|no>' line in CVS
> commit logs (put it in the template, default to yes?) and every 'yes'
> submit _must_ patch the cumulative release file.

I find it hard to imagine a patch that doesn't create *some* kind of
user-visible change, at some level.  The question here is whether it
rises to the level of needing an entry in the release notes.  If we
wanted a commit-by-commit release history we'd just tell people to read
the CVS logs; in practice that's no help.  The point of release notes is
to hit the high spots, and that requires a certain amount of judgment.

So I don't think a mechanical "you must provide this" rule will help
much.  We should rely on the judgment of the committer to decide whether
a release note is warranted.  What we want is a reasonably simple way
for the committer to provide a draft note, and a mechanism to ensure
that Bruce doesn't miss the note later.

In the case that started this thread, I had actually provided material
for a release note in the CVS commit entry, but Bruce had skipped over
it because he didn't think it important.  The missing link was that
I didn't have a way to plaster a "this is important" label on the
commit message.

Oh, here's another thought: including an explicit patch of the
pending-notes file in submissions won't work very well, since that part
of the patch will surely fail to apply if it's even a few days old.
It'll have to come in as separate text that the committer inserts into
the pending-notes file when he commits.  From this perspective, it might
be a lot easier to put the notes into CVS commit messages; there'll be
fewer problems with commit collisions.

			regards, tom lane

Fri, 08 Feb 2002 17:31:22 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Maintaining the list of release changes 